sunraj
asked on
message q's and message mapping
I have already asked this question ...but could not get convincing reply..
In traditional way of windows programming... when a windows messages is generated say WM_LBUTTONDOWN this message is put in 'system message queue'
then OS(windows nt) will remove this message from 'system message queue' and puts in 'window message queue'(each window is having separte mess.queue)'.
Then the window removes the message and asks the 'windows'(OS) to call the wndproc call back function to handle the message.
1. So there are one system message queue
and message queues for all the windows in an application. Further every window is having it's own wndproc. Is it correct ?
2. Can u explain in detail how messages are handled by the MFC.(wanted a brief explanation). will the message map macros call again win32 sdk function.
where does these 'getmessage', dispath message' function comes and called in mfc way of message mapping process ?
3. Which class is providing a message loop eithere CWinApp::Run or CWinthread::Run
Adv. thanks
In traditional way of windows programming... when a windows messages is generated say WM_LBUTTONDOWN this message is put in 'system message queue'
then OS(windows nt) will remove this message from 'system message queue' and puts in 'window message queue'(each window is having separte mess.queue)'.
Then the window removes the message and asks the 'windows'(OS) to call the wndproc call back function to handle the message.
1. So there are one system message queue
and message queues for all the windows in an application. Further every window is having it's own wndproc. Is it correct ?
2. Can u explain in detail how messages are handled by the MFC.(wanted a brief explanation). will the message map macros call again win32 sdk function.
where does these 'getmessage', dispath message' function comes and called in mfc way of message mapping process ?
3. Which class is providing a message loop eithere CWinApp::Run or CWinthread::Run
Adv. thanks
This article contains all answers on your questions.
http://www.devx.com/free/mgznarch/vcdj/1997/apr97/mfc1.asp
http://www.devx.com/free/mgznarch/vcdj/1997/apr97/mfc1.asp
1) Windows has a system message queue, but it's not exposed to applications. Devices put events in the queue, and Windows reads them and translates them into real application messages. This system queue exists once for the system, and Windows carefully prioritizes the way it decides to dispatch messages.
An application may have zero, one, or many message queues. If a thread within an application--even the primary thread--never calls a message-queue related function (like PeekMessage() or GetMessage()) it will never have a queue. If it does call such a function, it gets a queue. Since an app can have multiple threads, it might have multiple queues. A thread can process only messages in its own queue.
Your #2 and #3 questions are too intertwined:
MFC's CWinThread::Run() function has a message pump. There, MFC looks for messages that should be processed by the given thread. If it finds one, it looks in a map to see if the window handle for the message. If it finds a hit, it'll have the this pointer of the C++ CWnd-derived object that will be handling the message.
With that pointer, MFC gets the first message map. It looks through the map to see if there's a handler. If it finds no handler, it starts looking in related classes. It might also consider other windows--if the message is a command message, it might be reflected or routed. That's just a matter of picking another set of windows, using a few simple rules, to try to find a handler.
If a match is eventually found, MFC unpacks the parameters to the message (from wParam and lPAram) and makes them in to real C++ types. Then, it throws 'em on the stack and makes the call.
It's CWinThread::Run() that actually has the message pump. It calls PeekMessage(), and if a message is pending, it will call CWinThread::PumpMessage() to initiate the process I describe above.
Any good book on Windows or MFC should answer your questions. I explain all of these things in great detail in my own book. Jeff Richter's book explains it very well from a Win32 perspective, and Jeff Prosise's book is another good explanation from the MFC point of view.
..B ekiM
An application may have zero, one, or many message queues. If a thread within an application--even the primary thread--never calls a message-queue related function (like PeekMessage() or GetMessage()) it will never have a queue. If it does call such a function, it gets a queue. Since an app can have multiple threads, it might have multiple queues. A thread can process only messages in its own queue.
Your #2 and #3 questions are too intertwined:
MFC's CWinThread::Run() function has a message pump. There, MFC looks for messages that should be processed by the given thread. If it finds one, it looks in a map to see if the window handle for the message. If it finds a hit, it'll have the this pointer of the C++ CWnd-derived object that will be handling the message.
With that pointer, MFC gets the first message map. It looks through the map to see if there's a handler. If it finds no handler, it starts looking in related classes. It might also consider other windows--if the message is a command message, it might be reflected or routed. That's just a matter of picking another set of windows, using a few simple rules, to try to find a handler.
If a match is eventually found, MFC unpacks the parameters to the message (from wParam and lPAram) and makes them in to real C++ types. Then, it throws 'em on the stack and makes the call.
It's CWinThread::Run() that actually has the message pump. It calls PeekMessage(), and if a message is pending, it will call CWinThread::PumpMessage() to initiate the process I describe above.
Any good book on Windows or MFC should answer your questions. I explain all of these things in great detail in my own book. Jeff Richter's book explains it very well from a Win32 perspective, and Jeff Prosise's book is another good explanation from the MFC point of view.
..B ekiM
ASKER
dear mr.mikeblas could you start with a simple example say WM_LBUTTONDOWN. Now this message will go where...does it goes to system mess. queue...then will the operating system will notify the application that there is a message for it. Now cwinthread::run get's the message and dispatches the message to where....? when the message map macros comes into picture....
sunraj,
the CWinThread::Run() function makes a call to a member function called
PumpMessage(). This function implementation looks something like this:
::GetMessage(&m_msgCur,NUL
if(!PreTranslateMessage(&m
{
::TranslateMessage(&m_msgC
::DispatchMessage(&m_msgCu
}
DispatchMessage will route the messages to a Window Procedure. MFC's standard Window procedure is AfxWndProc(). This then calls the appropriate window object, where the message is received by the corresponding CWnd::WindowProc() function. This function parses the wParam and lParam values and calls member functions in CWnd derived classes.
hope this helps.
thanks
pagladasu
the CWinThread::Run() function makes a call to a member function called
PumpMessage(). This function implementation looks something like this:
::GetMessage(&m_msgCur,NUL
if(!PreTranslateMessage(&m
{
::TranslateMessage(&m_msgC
::DispatchMessage(&m_msgCu
}
DispatchMessage will route the messages to a Window Procedure. MFC's standard Window procedure is AfxWndProc(). This then calls the appropriate window object, where the message is received by the corresponding CWnd::WindowProc() function. This function parses the wParam and lParam values and calls member functions in CWnd derived classes.
hope this helps.
thanks
pagladasu
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
wow mikeblas, that was really a comprehensive explanation. since you have started the explanation, there are a few queries here.
Regarding the message map maintained by MFC, is a single message map maintained for all windows objects (more specifically CCmdTarget derived object). what exactly is the structure of this message map?
Can you give us an idea of how the special cases skipped by you are handled - i.e. dialog messages and window creation messages.
Regarding the message map maintained by MFC, is a single message map maintained for all windows objects (more specifically CCmdTarget derived object). what exactly is the structure of this message map?
Can you give us an idea of how the special cases skipped by you are handled - i.e. dialog messages and window creation messages.
> that was really a comprehensive explanation
It sure is. And all for only seventy points!
> Regarding the message map maintained by MFC, is a
> single message map maintained for all windows objects
> (more specifically CCmdTarget derived object).
> what exactly is the structure of this message map?
This is described and answered in great detail in my book.
..B ekiM
It sure is. And all for only seventy points!
> Regarding the message map maintained by MFC, is a
> single message map maintained for all windows objects
> (more specifically CCmdTarget derived object).
> what exactly is the structure of this message map?
This is described and answered in great detail in my book.
..B ekiM
Please remember to grade your question.
..B ekiM
..B ekiM
mikeblas, i appreciated your answer, but i did not ask it. only sunraj, who actually asked it can do so.
> only sunraj, who actually asked it can do so.
Of course. It was him whom I was addresing.
..B ekiM
Of course. It was him whom I was addresing.
..B ekiM
It's been nearly a month. Please grade your answer before the autograder cheats me.
..B ekiM
..B ekiM
Yes u are right. There are 2 queues one for windows and another for windows window.
1)If u register u r class then u can have u r own windproc. Else the default window procedure will be called.
2)The dispatch message and translate message are there in CWinThread class. U r CWinApp class is derived from CWinThread. They are in implemented in the CWinThread::Run() function. U can also override this function to know the details. U can see the source files where CWinThread class is implemented.
3) Its CWinThread::Run()