Global Dialog in MFC for WinCe 5.0 from a thread (using CreateThread)
I have a multi-window application. There can be several windows all one on top of another.
I am planning on creating a thread that will block on an event. The event will fire via an interrupt. After it fires, I would like to display a simple dialog that will ask the user if they wish to shutdown the device? If they answer yes, a GPIO pin will be set and this will cause the power to be turned off. The question is how do I create a dialog from this thread and make it the top most window. I already know how to change the z-order of a window, what I need is an example showing how to instantiate the dialog from the thread and display it.
Can someone point me to some sample code as to how to do this?
Thanks in advance!
I am planning on creating a thread that will block on an event. The event will fire via an interrupt. After it fires, I would like to display a simple dialog that will ask the user if they wish to shutdown the device? If they answer yes, a GPIO pin will be set and this will cause the power to be turned off. The question is how do I create a dialog from this thread and make it the top most window. I already know how to change the z-order of a window, what I need is an example showing how to instantiate the dialog from the thread and display it.
Can someone point me to some sample code as to how to do this?
Thanks in advance!
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
>>I recommend that you not have the thread make any U/I calls. For instance, a SendMessage from the >>thread would execute code that is in a non-threaded (U/I) object. That is almost certain to casue problems.
Actually no. Problems happen when you try to access (window) objects directly from different threads. SendMessage and PostMessage differ in that SendMessage waits for it to be handled, PostMessage returns immediately, just placing the message in the queue. Important is to use the HWND for both instances.
That is not how you described your situation at all, SendMessage ought to be safe to use.
Actually no. Problems happen when you try to access (window) objects directly from different threads. SendMessage and PostMessage differ in that SendMessage waits for it to be handled, PostMessage returns immediately, just placing the message in the queue. Important is to use the HWND for both instances.
That is not how you described your situation at all, SendMessage ought to be safe to use.
Yes, that is correct. Using
::SendMessage( hwndSomeOtherWindow, x,y,z )
will set the mesage to be processed after a task switch to the thread that created hwndSomeOtherWindow
But using:
pSomeCwndPtr->SendMessage( x,y,z);
from a thread that did not create pSomeCWndPtr is bound to cause problems.
From the desription of the question, it appears Anthony2000 is thinking of creating and managing a dialog box from a worker thread. It is important to avoid that. Instead, have the worker thread trigger the main U/I thread to do the action.
One more thought:
Using ::SendMessage might have an unintended consequence. The calling thread is blocked untill the called window processes the mesage (some messages take a long time to process). Depending on the scenario, that might be a problem... will the thread miss the next interrupt /event because it is blocked waiting for the GUI?
::SendMessage( hwndSomeOtherWindow, x,y,z )
will set the mesage to be processed after a task switch to the thread that created hwndSomeOtherWindow
But using:
pSomeCwndPtr->SendMessage( x,y,z);
from a thread that did not create pSomeCWndPtr is bound to cause problems.
From the desription of the question, it appears Anthony2000 is thinking of creating and managing a dialog box from a worker thread. It is important to avoid that. Instead, have the worker thread trigger the main U/I thread to do the action.
One more thought:
Using ::SendMessage might have an unintended consequence. The calling thread is blocked untill the called window processes the mesage (some messages take a long time to process). Depending on the scenario, that might be a problem... will the thread miss the next interrupt /event because it is blocked waiting for the GUI?
I see you agree with my original comment which told to use HWND's and informed about the thread being blocked - which, if suitable, simplifies matters.
Note the asker is asking for a dialog box to behave modally. Said dialog gives the user a binary choice and the worker thread requires only the result and is to wait for the result (thread is blocked).
ASKER
I will be trying this sometime next week. Sorry for the delay in getting back to you.
ASKER
Thanks guys. I used a combination of both of your ideas. Thanks again for your help!!
ASKER