Re: Message Maps
On 6 Jun 2006 10:26:53 -0700, canilao1@yahoo.com wrote:
You're right this is not my real code. I was just demostrating that I
needed messaging to be mapped from "grandchildren". The reason why it
is not created as a member, is because my actual design creates
windows/buttons/edit boxes dynamically. A particular window that is
created by this manager object, can take any form of buttons, edit
boxes etc. This all depends on data that is recieved by my manager
class. This design causes me to have, "grandchildren".
As David said, child windows send messages to their parents. You want the
"grandparent" to handles these messages. There are a couple of possible
approaches:
1. The parent could forward these messages to its parent.
2. The grandparent could override PreTranslateMessage, which should let it
see the messages coming to its descendants that are mapped to MFC controls.
3. You might be able to reparent the controls after they're created. I've
forgotten the details, but this can be done with either SetParent or maybe
SetOwner to redirect notification messages to another window.
My next question would be, is there good way to dynamically create MFC
objects and set up generic handlers for what ever is created? That's
my real problem. Right now I'm going to use a custom messaging system.
But if there is a better MFC way, I am dying to know.
MFC has a message routing system for WM_COMMAND messages, which can be
routed between views, frames, documents, and the application; it's possible
to insert yourself anywhere in the chain. This routing doesn't apply to
dialogs or other message types, but as mentioned earlier,
PreTranslateMessage provides a sort of routing of all messages to MFC
ancestor windows, provided the original message target is mapped to a CWnd.
--
Doug Harrison
Visual C++ MVP