PostThreadMessages lost in DLL
-
I have a DLL that has a class derived from CWinApp. I have another class in the DLL that needs to trigger an asynchronous process within that same DLL. Since the DLL has no window I use PostThreadMessage to trigger the process as follows:
void CMyClass::TriggerAsyncProc() const { AfxGetApp()->PostThreadMessage(WMU_MYMSG, 0, 0L) ; }In my class derived from CWinApp, I have tried two different methods to trap WMU_MYMSG. The first was to override PreTranslateMessage, and the second was to try to use the CWinApp message map (via ON_THREAD_MESSAGE). The DLL is being used by a dialog application, and the TriggerAsyncProc is definately sending the message because PostThreadMessage(WMU_MYMSG, 0, 0L) returns non-zero. The only thing I can think of is that my message is going through the message map of the dialog application instead of my class derived from CWinApp in the DLL. Please can someone tell me why I'm losing the message, and suggest either how I correct this or an alternative method? Thanks. :confused: -
I have a DLL that has a class derived from CWinApp. I have another class in the DLL that needs to trigger an asynchronous process within that same DLL. Since the DLL has no window I use PostThreadMessage to trigger the process as follows:
void CMyClass::TriggerAsyncProc() const { AfxGetApp()->PostThreadMessage(WMU_MYMSG, 0, 0L) ; }In my class derived from CWinApp, I have tried two different methods to trap WMU_MYMSG. The first was to override PreTranslateMessage, and the second was to try to use the CWinApp message map (via ON_THREAD_MESSAGE). The DLL is being used by a dialog application, and the TriggerAsyncProc is definately sending the message because PostThreadMessage(WMU_MYMSG, 0, 0L) returns non-zero. The only thing I can think of is that my message is going through the message map of the dialog application instead of my class derived from CWinApp in the DLL. Please can someone tell me why I'm losing the message, and suggest either how I correct this or an alternative method? Thanks. :confused:This doesn't sound like it would work. A DLL that has a CWinApp object is supported, but that CWinApp object doesn't have its own message pump. I wouldn't expect any messages to be processed in the DLL's CWinApp object unless you've tweaked something to do so. Here's what the docs state about this situation: "Note that the CWinApp::Run mechanism does not apply to a DLL, because the application owns the main message pump. If your DLL brings up modeless dialogs or has a main frame window of its own, your application's main message pump must call a DLL-exported routine that calls CWinApp::PreTranslateMessage." Mark
Mark Salsbery Microsoft MVP - Visual C++ :java:
-
This doesn't sound like it would work. A DLL that has a CWinApp object is supported, but that CWinApp object doesn't have its own message pump. I wouldn't expect any messages to be processed in the DLL's CWinApp object unless you've tweaked something to do so. Here's what the docs state about this situation: "Note that the CWinApp::Run mechanism does not apply to a DLL, because the application owns the main message pump. If your DLL brings up modeless dialogs or has a main frame window of its own, your application's main message pump must call a DLL-exported routine that calls CWinApp::PreTranslateMessage." Mark
Mark Salsbery Microsoft MVP - Visual C++ :java:
Thanks for that. It's a pity that the DLL Wizard created a CWinApp derived class that includes Message Map macro declarations. There is a possiblity that the main applications using my DLL will not have a main frame window - they may also be ATL applications. Please could you advise what I could do in these cases? Thanks
-
Thanks for that. It's a pity that the DLL Wizard created a CWinApp derived class that includes Message Map macro declarations. There is a possiblity that the main applications using my DLL will not have a main frame window - they may also be ATL applications. Please could you advise what I could do in these cases? Thanks
I would suggest reading this: Kinds of DLLs[^] It outlines the methods and requirements of different MFC DLL scenarios. Maybe it'll help choose an appropriate method for your needs. Mark
Mark Salsbery Microsoft MVP - Visual C++ :java:
-
I would suggest reading this: Kinds of DLLs[^] It outlines the methods and requirements of different MFC DLL scenarios. Maybe it'll help choose an appropriate method for your needs. Mark
Mark Salsbery Microsoft MVP - Visual C++ :java:
-
Thanks again. Not a lot of help there about this particular situation, but some useful info. none the less. Cheers.
What I have done within a DLL 'init' function that the client must call - AFTER the client has already loaded all its dll and such, is to create a new thread. All the work within the DLL I wrote was done from within this thread internal to the DLL. At the top of this thread place a PeekMessage call, so the thread will get a message queue. Then you can process 'posted thread messages' fromt this thread and it has its own independent message pump. Just because an app stared as a dialog app, or some other type of app, does not mean it can't have a DLL containing its own thread and its own message queue.
-
Thanks again. Not a lot of help there about this particular situation, but some useful info. none the less. Cheers.
Yeah. The main point is... when using MFC in a "regular DLL" (that can be used by an MFC or non-MFC app) then you have to provide the message pump. There's also subtle differences in MFC initialization, but if you use the wizards, that code is created for you. Mark
Mark Salsbery Microsoft MVP - Visual C++ :java: