|
| Home |
|
|
Message Flow and RoutingRTPEG-32 follows a bottom-up message flow philosophy. This means that messages are sent directly to the lowest level object that should receive the message. If the object does not want to process the message, it passes it on to the message handler of its base class. Since all visible objects are derived from PegThing, unhandled messages will eventually arrive at the handler of PegThing, which passes the message to the parent of the current object. Again, the message can travel down the object's hierarchy, and eventually to the parent's parent, etc. Once PegThing's handler finds it has no parent, the message is discarded. Many messages, especially user defined messages, may be directed towards a particular object by the pTarget message field or by the message iData field. If pTarget is anything other than NULL, the message is always sent directly to the object pointed to by pTarget. Other messages do not have a particular object as their target. Examples of these message include mouse, touch screen, and keyboard messages. In these cases the pTarget member of the message is set to NULL, and it is the responsibility of PegPresentationManager to determine which object should receive the message. When a user defined message is pulled from the message queue and it has a pTarget value of NULL, the message routing functions assume that the message iData field contains the ID of the object that should receive the message. This means there are two ways of directing user defined messages to particular objects. The pTarget field can contain an actual pointer to the destination object, which always takes precedence, or pTarget can be NULL and PegPresentationManager will route the message to the first object found with an ID value matching the message iData member. If you want to route user defined messages using object ID values, those objects should have globally defined object IDs to insure that there are never multiple objects visible with duplicate ID values. Whenever an object sends a system-defined message to its parent window, the message contains a pointer to the object that sent the message. This pointer is contained in the message field pSource. This makes it very easy to identify the sender of the message and perform operations such as modifying the appearance of the object, interrogating the object for additional information, etc.
|
