Message Queues for MFC windows classes
-
Hi We know that Windows keeps a message queue for every thread. If i am not wrong for win32 applications, only one message loop is enough. But in MFC applications, we have Message Map macros(DECLARE_MESSAGE_MAP/BEGIN_MESSAGE_MAP/END_MESSAGE_MAP) for every window class. Mainfrm, chidfrm, childview, doc etc.. Do all of the message map macros that we see in the source code indicate there is a message loop that buried in MFC source code? I couldn't make relation between win32 message handling and MFC message handling. Thanks...
-
Hi We know that Windows keeps a message queue for every thread. If i am not wrong for win32 applications, only one message loop is enough. But in MFC applications, we have Message Map macros(DECLARE_MESSAGE_MAP/BEGIN_MESSAGE_MAP/END_MESSAGE_MAP) for every window class. Mainfrm, chidfrm, childview, doc etc.. Do all of the message map macros that we see in the source code indicate there is a message loop that buried in MFC source code? I couldn't make relation between win32 message handling and MFC message handling. Thanks...
sawerr wrote:
We know that Windows keeps a message queue for every thread.
Only if you call a function that causes a queue to be created on a thread.
sawerr wrote:
for win32 applications, only one message loop is enough.
Yes, one is sufficient, but not necessary unless you create at least one window. For example, you don't need a message loop in a console app.
sawerr wrote:
Do all of the message map macros that we see in the source code indicate there is a message loop that buried in MFC source code?
Yes, but not a separate message loop for each window/class. There's still one per UI thread. See the source code for CWinThread::Run() - the per-thread message loop is there. The CWinApp class derives from CWinThread, so for an MFC GUI app, your required CWinApp object generally provides the first/main message loop. Once messages are extracted from the queue in a message loop, then they are dispatched to their destination window via a call to the destination window's windowproc (window procedure). That's basic Windows windowing[^]. The message map table macros generate compiled code that maps a message received in the windowproc to a call to the appropriate window class method. Hope that makes a little sense. Mark
Mark Salsbery Microsoft MVP - Visual C++ :java:
-
sawerr wrote:
We know that Windows keeps a message queue for every thread.
Only if you call a function that causes a queue to be created on a thread.
sawerr wrote:
for win32 applications, only one message loop is enough.
Yes, one is sufficient, but not necessary unless you create at least one window. For example, you don't need a message loop in a console app.
sawerr wrote:
Do all of the message map macros that we see in the source code indicate there is a message loop that buried in MFC source code?
Yes, but not a separate message loop for each window/class. There's still one per UI thread. See the source code for CWinThread::Run() - the per-thread message loop is there. The CWinApp class derives from CWinThread, so for an MFC GUI app, your required CWinApp object generally provides the first/main message loop. Once messages are extracted from the queue in a message loop, then they are dispatched to their destination window via a call to the destination window's windowproc (window procedure). That's basic Windows windowing[^]. The message map table macros generate compiled code that maps a message received in the windowproc to a call to the appropriate window class method. Hope that makes a little sense. Mark
Mark Salsbery Microsoft MVP - Visual C++ :java:
For example if we want to use Edit control in win32 app, the code will be:
hEdit = CreateWindowEx(WS_EX_CLIENTEDGE, "EDIT", "",
WS_CHILD | WS_VISIBLE | WS_VSCROLL | WS_HSCROLL | ES_MULTILINE | ES_AUTOVSCROLL | ES_AUTOHSCROLL,
0, 0, 100, 100, hwnd, (HMENU)IDC_MAIN_EDIT, GetModuleHandle(NULL), NULL);
//http://www.winprog.org/tutorial/app_one.html[^]Here we create a "control". That control has a message loop in its source code which was written by controls developer. If an event happens, it is sent to its module(for example user32.dll) not to our application. It sends to our program a notification. OK. But in MFC, We use CEditView which is derived from CView. So we create a new window. And CreateWindowEx(WS_EX_CLIENTEDGE, "EDIT", "",...) is in the CEditView. Has that view window got a message loop too? If no, how can we handle for example WM_CLOSE
//class CTextView : public CEditView
void CTextView::OnClose()
{
// TODO: Add your message handler code here and/or call defaultCEditView::OnClose();}
You said:
Mark Salsbery wrote:
The CWinApp class derives from CWinThread, so for an MFC GUI app, your required CWinApp object generally provides the first/main message loop
If view window has a message loop, is that mean it is created by a new thread? For example, When user close this CeditView window, is this message sent to Main Window or View Window? If it is sent to main window, does main window route it to view window? I'm sorry, i really don't solve/understand the mechanism... Thank you.
-
For example if we want to use Edit control in win32 app, the code will be:
hEdit = CreateWindowEx(WS_EX_CLIENTEDGE, "EDIT", "",
WS_CHILD | WS_VISIBLE | WS_VSCROLL | WS_HSCROLL | ES_MULTILINE | ES_AUTOVSCROLL | ES_AUTOHSCROLL,
0, 0, 100, 100, hwnd, (HMENU)IDC_MAIN_EDIT, GetModuleHandle(NULL), NULL);
//http://www.winprog.org/tutorial/app_one.html[^]Here we create a "control". That control has a message loop in its source code which was written by controls developer. If an event happens, it is sent to its module(for example user32.dll) not to our application. It sends to our program a notification. OK. But in MFC, We use CEditView which is derived from CView. So we create a new window. And CreateWindowEx(WS_EX_CLIENTEDGE, "EDIT", "",...) is in the CEditView. Has that view window got a message loop too? If no, how can we handle for example WM_CLOSE
//class CTextView : public CEditView
void CTextView::OnClose()
{
// TODO: Add your message handler code here and/or call defaultCEditView::OnClose();}
You said:
Mark Salsbery wrote:
The CWinApp class derives from CWinThread, so for an MFC GUI app, your required CWinApp object generally provides the first/main message loop
If view window has a message loop, is that mean it is created by a new thread? For example, When user close this CeditView window, is this message sent to Main Window or View Window? If it is sent to main window, does main window route it to view window? I'm sorry, i really don't solve/understand the mechanism... Thank you.
sawerr wrote:
Here we create a "control". That control has a message loop in its source code which was written by controls developer.
No, it doesn't. It has a window procedure implemented by the control developer. You are still responsible for providing a message loop. You're confusing message loops with window procedures. Window procs are related to the window class. MFC subclasses windows so the MFC framework gets first peek at messages before forwarding unhandled (i.e. no message map entry) messages to the original window proc.
sawerr wrote:
If view window has a message loop, is that mean it is created by a new thread?
That doesn't make sense. Windows don't have message loops. Threads can implement a message loop. Windows have window procedures, which are functions called by the system to send a window a message. Study the link I gave you on windowing. It's the fundamentals of Windows programming, and in my opinion, essential to know and understand completely to be an effective Windows programmer. If you need more drawn-out documentation on how it all works, then I recommend the book "Windows Programming" by Charles Petzold. Mark
Mark Salsbery Microsoft MVP - Visual C++ :java:
-
sawerr wrote:
Here we create a "control". That control has a message loop in its source code which was written by controls developer.
No, it doesn't. It has a window procedure implemented by the control developer. You are still responsible for providing a message loop. You're confusing message loops with window procedures. Window procs are related to the window class. MFC subclasses windows so the MFC framework gets first peek at messages before forwarding unhandled (i.e. no message map entry) messages to the original window proc.
sawerr wrote:
If view window has a message loop, is that mean it is created by a new thread?
That doesn't make sense. Windows don't have message loops. Threads can implement a message loop. Windows have window procedures, which are functions called by the system to send a window a message. Study the link I gave you on windowing. It's the fundamentals of Windows programming, and in my opinion, essential to know and understand completely to be an effective Windows programmer. If you need more drawn-out documentation on how it all works, then I recommend the book "Windows Programming" by Charles Petzold. Mark
Mark Salsbery Microsoft MVP - Visual C++ :java: