How to post message from
richard
CMainFrame* pMainFrame = new CMainFrame;
From this mainframe I'd like to have a modeless dialog box pop up. If this
dialog closes, how can make it to inform the mainframe about the closing?
Should I use PostMessage, or PostThreadMessage? If using PostThreadMessage,
how can I get the thread id for the mainframe window? If using PostMessage,
then how to get the mainframe's window handle?
Thanks for your help!
Ajay Kalra
object. There is really no need for using PostThreadMessage().
On Other note, CMainFrame is not really created, until you call
Create/CreateEx etc.
--
Ajay Kalra [MVP - VC++]
ajay...@yahoo.com
"richard" <notew...@appdev.com> wrote in message
news:iF5O9.77701$hK4.6...@bgtnsc05-news.ops.worldnet.att.net...
Joseph M. Newcomer
is using a menu, a MessageBox, and/or a dialog, the thread message can be discarded.
joe
Joseph M. Newcomer [MVP]
email: newc...@flounder.com
Web: http://www3.pgh.net/~newcomer
MVP Tips: http://www3.pgh.net/~newcomer/mvp_tips.htm
richard
news:o99i0vkbvg41mugqr...@4ax.com...
> Just use PostMessage. PostThreadmessage will not work reliably, because if
the main window
> is using a menu, a MessageBox, and/or a dialog, the thread message can be
discarded.
> joe
>
Thanks! Why "PostThreadmessage will not work reliably"?
How can the window handle of the first argument of PostMessage be obtained?
Ajay Kalra
I dont know why this would not work. I have been using it for a long time
without a problem. You have to handle it in your WinApp object.
> How can the window handle of the first argument of PostMessage be
obtained?
You can use this: AfxGetMainFrame()->PostMessage(...) // Here you dont need
the handle. This of cource assumes AfxGetMainWnd() is valid.
You can always the handle from AfxGetMainWnd()->m_hWnd; // It public(??)
member of CWnd
--
Ajay Kalra [MVP - VC++]
ajay...@yahoo.com
"richard" <notew...@appdev.com> wrote in message
news:6CoO9.12686$p_6.1...@bgtnsc04-news.ops.worldnet.att.net...
Joseph M. Newcomer
app has special code to handle the receipt of a thread message, which has an HWND of NULL.
However, if you have a menu active when the message is received, or a MessageBox, these
have their own private message pump, which simply does
TranslateMessage()
DispatchMessage()
and if the HWND is NULL the message is effectively discarded, because there is noplace to
dispatch it to.
AfxGetMainWnd() is not valid in a thread (actually, it is; it returns a reference to the
main window of the thread, which is almost always NULL for most threads. It is always NULL
for a worker thread, and it is usually NULL for a UI thread unless you have taken special
effort to set the m_pMainWnd member of the UI thread to something other than NULL.
So if you have seen PostThreadMessage work "reliably" in posting messages to the main GUI
thread, you have simply been lucky. It is not to be considered reliable in posting to any
thread that can have a secondary message loop.
Note that the documentation suggests that this also applies to dialogs. In general, a
dialog also has its own private message loop. However, MFC dialogs are not modal (they
only give the illusion of modality) and are handled by the standard MFC message handling
capability, and therefore (in theory) should handle thread messages. However, a non-MFC
dialog would definitely fail (such as one that might be created from a DLL with its own
message pump and dialog resource, which suggests potential problems with the standard
dialogs as well).
joe
On Wed, 25 Dec 2002 12:48:29 -0800, "Ajay Kalra" <ajay...@yahoo.com> wrote:
>> Thanks! Why "PostThreadmessage will not work reliably"?
>
>I dont know why this would not work. I have been using it for a long time
>without a problem. You have to handle it in your WinApp object.
>
>> How can the window handle of the first argument of PostMessage be
>obtained?
>
>You can use this: AfxGetMainFrame()->PostMessage(...) // Here you dont need
>the handle. This of cource assumes AfxGetMainWnd() is valid.
>
>You can always the handle from AfxGetMainWnd()->m_hWnd; // It public(??)
>member of CWnd
Joseph M. Newcomer [MVP]
Ajay Kalra
Thanks for explanation.
We have been using it for a long time but I think its still OK. Its used
before the main window is created and there is no secondary UI/Worker
thread. All done in MFC MDI application. I was not the one who did it but I
was sort of surprised at its use as it could have been very well done using
a PostMessage after the mainframe has been created.
--
Ajay Kalra [MVP - VC++]
ajay...@yahoo.com
"Joseph M. Newcomer" <newc...@flounder.com> wrote in message
news:014l0vcjv3rh0jojj...@4ax.com...
Goran Pusic
void MyModelessDialogClosed() { DoStuff(); }
and call it from dialog's OnClose. It's one message map entry and one WM_
constant less.
If you don't like cluttering your main frame interface, you could make
dialog a friend of the frame and make a method private. Because the dialog
is modeless, chances are that it actually controls the frame (or something
else) somehow already, so it knows about its specifics not present in a
vanilla CFrameWnd, so it's not important that it uses MyModelessDialogClosed
(or whatever), too.
Also, it is often the case that your dialog is actually "conceptually"
connected to a document. If so, it might prove good to use UpdateAllViews
instead (especially if the dialog closes with "OK", or "Apply"). I say that
because usually, a frame normally does not do a lot in an app but doc/view
stuff does.
Goran.
"richard" <notew...@appdev.com> wrote in message
news:iF5O9.77701$hK4.6...@bgtnsc05-news.ops.worldnet.att.net...