http://groups.google.com/group/microsoft.public.vc.mfc/browse_thread/thread/84f7fa99a1420f45/764a39013fb7abd1?lnk=st&q=MFC+secondary+message+loop&rnum=1&hl=en#764a39013fb7abd1
a. Unless a secondary message loop is running WM_USER based messages
message. In thrdcore.cpp there is a function AfxInternalPumpMessage
b. However if a secondary message loop is running then the message loop
so no PreTranslateMessage can kick in. (Please refer to the thread
Ah!
a lot of new stuff for me :-)
Firstly, the ON_MESSAGE handler worked.
But now I am confused about WM_APP based messsages.
In my app I am responding to the mouse scroll messages also. The code
which does scrollign for mouse scroll is same as that for the scroll
bar.
In both cases I post WM_APP based messages to the CFrameWnd derived
class.
For mouse scroll, the WM_APP based message is gettign routed thru the
CWinApp. If I put a PreTranslateMessage in the CWinApp derived class I
see the WM_APP message.
But when the user scrolls using the scroll bar, the WM_APP message is
not getting routed thru the CWinApp. For some reasons, the code which I
was given to maintain already had a PreTranslateMessage over-ridden in
the CWinApp derived class. This used to do some special handling for
the message. As mentioned in this thread before, previously the app
used to Post thread messages. I had changed it to post to a specific
window.
I put a PreTranslateMessage in the CFrameWnd derived class the message
did not show up there. But if I put up a ON_MESSAGE handler I am able
to handle messages.
Pardon my ignorance but where is this "secondary message loop"
mentioned in MSDN?
I did a search in MSDN, but nowhere does it mention that WM_APP based
messages wont result in PreTranslateMessage call on the window.
From what I am seeing is that only if the "secondary message loop" is
running, the WM_APP based messages are not getting routed to the
CWinApp.
Regards
Chiman
Joseph M. Newcomer wrote:
Using PreTranslateMessage in this fashion constitutes PreTranslateMessage abuse. It is
inappropriate, and in any case, there is no guarantee that it will work correctly when
there is a secondary message loop. Also, many messages are not routed to the CWinApp,
including user-defined messages, so putting a PreTranslateMessage there is completely
pointless. You can only handle user-defined window messages in CWnd-derived classes (and
you can handle thread messages in a CWinThread-derived classes, and this does include
CWinApp). But whenever you start to think "PreTranslateMessage", take as given that there
is a *significant* chance what you are doing won't work.
Your observation, "the message was not getting routed to the CFrameWnd class" is very
confusing, because (a) user-defined messages are *never* routed to *any* class under *any*
conditions and (b) if you wanted something routed to the CFrameWnd, why are you talking
about a filter in a CWinApp class? They are not related!
User-defined messages are sent to the window they are sent/posted to, period. There is no
routing of any kind going on (note that superclass message table searching is *not*
"routing")
PreTranslateMessage has its uses, and they are important. But most uses are from people
who don't understand it, and are therefore surprised when it doesn't work under conditions
it was never intended to work in. So assume that, unless there is compelling evidence
that it is absolutely necessary, that using it is a mistake. That way you won't hit the
kind of problems you've just described. Learn to use Message Maps correctly.
joe
On 3 Sep 2006 22:00:03 -0700, "Chimanrao" <chimanrao@gmail.com> wrote:
hi,
I did all the recommended things:
a. Tried posting directly to a Window, In my Case a CFrameWnd derived
class,
b. Used WM_APP based definition for the messages.
Both cases did not solve my problem.
I put up a message filter Hook, I found my custom message appearing
there, the window handle was also correct.
However during scrolling the custom message just did not appear in
CWinApp derived class's PreTranslateMessage. So the message was not
getting routed to the CFrameWnd derived class.
I ended up using the message filter function to route my message
specifically.
Regards
Chiman
Joseph M. Newcomer wrote:
It wouldn't surprise me that these messages are lost, because you don't send them
anywhere. I presume you are using ::PostMessage, not CWnd::PostMessage, because of the
initial meaningless parameter NULL. This causes it to behave like PostThreadMessage,
which is DOCUMENTED (RTFM) as failing under a variety of conditions, such as when you are
in a modal loop. Scrolling is an example of a modal loop. If you have a CWnd* reference
to the window, call CWnd::PostMessage; if all you have is an HWND, use it! But don't use
NULL. You can't PostThreadMessage to a GUI thread that has user-visible elements. So
your code is incorrect, and will not work correctly until you fix it.
Also, you should consider using WM_APP messages or better still Registered Window
Messages.
joe
On 31 Aug 2006 20:56:59 -0700, "Chimanrao" <chimanrao@gmail.com> wrote:
hi,
In my app when the user scrolls using the scroll bar, I post some
WM_USER based messages to to my main thread loop using the call
PostMessage(NULL,WM_SOME_MSG,wparam,lparam);
Whats happening is that this message is getting lost.
However if the user scrolls using the mouse wheel, this message is
being received.
Does windows handle messages differently while scrolling is on?
Regards
Chiman
Joseph M. Newcomer [MVP]
email: newcomer@flounder.com
Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm
Joseph M. Newcomer [MVP]
email: newcomer@flounder.com
Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm