• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 836
  • Last Modified:

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!
0
Anthony2000
Asked:
Anthony2000
  • 4
  • 3
  • 2
2 Solutions
 
AndyAinscowCommented:
I hope this does work on WinCE - this is the classic windows way.

This isn't quite what you ask for but it is likely to be the simplest.  
I hope it would be a viable method.  (Because UI Threads are more complex than simple worker threads).

Pass the thread the HWND of the main application window (typically before it is started).
When the thread needs the result it should pass a message to the main window of the app (SendMessage will force the thread to wait until the message returns).
The main window of the app then displays the dialog as a modal dialog.
When the modal dialog is closed the result is passed back as the return parameter of the SendMessage call.

If you need the thread to keep alive rather than waiting then you use PostMessage and use a polling for an event the main app would raise after the dialog is finished.  I'll go into that in more detail should you require it.
0
 
Anthony2000Author Commented:
I will try this and get back to you. It does sound like it should work!! I will kick off the thread from the main application window.
0
 
DanRollinsCommented:
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. See:
    Multithreading -- Why and When
   http://www.experts-exchange.com/A_1635.html
   Simple Multithreading in Visual C++
    http://www.experts-exchange.com/A_1636.html
Instead, use PostMessage to notify the main window to do something.
Another option is to set simple m_fShutDownNow Boolean in the main window object, and use a timer in the main window to check that flag every so often.
I don't now about CE, but in regular Windows, you will still have a significant issue to solve: If another app has the focus (is in the foreground), then your app cannot popup a window that will be certain to be seen. Most programs these days use a "desktop notification" technique in which a small window "slides out" near the tray area of the taskbar. See:
    MFC Feature Pack for VS 2008 and 2010
    http://www.experts-exchange.com/A_2128.html
... for a simple way to do that.

Fig1-9.jpg
0
VIDEO: THE CONCERTO CLOUD FOR HEALTHCARE

Modern healthcare requires a modern cloud. View this brief video to understand how the Concerto Cloud for Healthcare can help your organization.

 
AndyAinscowCommented:
>>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.
0
 
DanRollinsCommented:
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?
0
 
AndyAinscowCommented:
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.

0
 
AndyAinscowCommented:
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).
0
 
Anthony2000Author Commented:
I will be trying this sometime next week. Sorry for the delay in getting back to you.
0
 
Anthony2000Author Commented:
Thanks guys. I used a combination of both of your ideas. Thanks again for your help!!
0

Featured Post

What does it mean to be "Always On"?

Is your cloud always on? With an Always On cloud you won't have to worry about downtime for maintenance or software application code updates, ensuring that your bottom line isn't affected.

  • 4
  • 3
  • 2
Tackle projects and never again get stuck behind a technical roadblock.
Join Now