Windows Messages

[Wyman A Belts]

Hi Everyone,
Can someone explain to me exactly what happens to Windows messages in DDT? Let's say I have a control on a dialog and I've created a callback for both. When a message is sent to the control from Windows, what happens to that message if I respond or don't respond to it (ie setting the value of the callback function to the value of the message)? I'm trying to understand the Control Callback-->Dialog Callback-->Windows Default Window Handler relationship and when messages fall through and when they don't? Is this in the help file somewhere? I hope this is clear what I'm asking. Thanks in advance for your help,

-------------
[email protected]

[Scott Hauser]

hi wyman,

jim huguley wrote this example and it is quite entertaining.



hth

------------------

[Chris Boss]

Wyman;

DDT Callbacks "do not process messages to a control" !

They process messages from a control (or Windows) to the Parent Dialog. The common message processed by a controls Callback is the %WM_COMMAND message which is used to process common events, like a mouse click or a control getting focus.

The example posted above, is dealing with "subclassing" which isn't done using DDT callbacks. You must subclass the control and Windows will send messages to your custom Window procedure (a form of Callback, but SDK style not DDT) and your custom window procedure must pass on unprocessed messages to the original Window procedure.

The DDT Callback procedure is quite limited since it only handles certain messages that the Parent Dialog receives for a control. To fully appreciate what DDT is doing it is best to examine some SDK style code first and see how messages to the Parent Dialog for controls is normally handled (%WM_COMMAND and %WM_NOTIFY messages).

Subclass on the other hand requires a little more experience, because you are now "intercepting" messages to a control and improper processing will cause the control to act improperly. Also controls receive "many more" messages than most realize, so be carefully in how you process them (when subclassing).


------------------

[Lance Edmonds]

To answer the original question...
DDT encapsulates the Windows dialog engine, so to undrestand what DDT does behind the scenes requires an understanding of how Windows creates and handles modal and modeless dialogs boxes.

Briefly, when a dialog callback receives a message, the callback function can either process or ignore the message.

If the message is processed, then the dialog function should return a value to indicate this fact (usually non-zero, but it is often message-dependant). When this return value is returned to Windows, it will either pass the message on to the default dialog box engine handler (DefDlgProc()), or it will do nothing further with the message (ie, your callback returned a non-zero value).

For example, in a dialog callback, if your code processes the %WM_INITDIALOG message, it should return false if you want the dialog box engine to handle setting focus to the default control, or you should return TRUE (non-zero) if you want Windows to respect your choice for default focus (ie, you may call SetFocus() in the message handler.

Another good example if %WM_ERASEBKGND. If you return non-zero to this message, then Windows assumes that your code handled the repainting of the window's background and do nothing. If your code does nothing (or returns FALSE), then Windows repaints the Window background using the the appropriate brush (usually GRAY for a dialog in Win32).

This "signalling" technique means that it is also possible to process a message, and also let Windows perform the default action as well. This can be a useful trick in some circumstances too!

When a DDT control sends a message, the message is first routed to the control callback (if there is one). If this function does not exist, or the function returns 0, then the message is rerouted to the dialog callback. If this callback does nothing with the message (or the dialog callback does not exist), then the message is sent to the DDT dialog box engine for default behavior processing.


To expand Chris's reply slightly...

Subclassing is a technique that permits a programmer to "alter" the default behavior of an existing control or window. This is also known as "instance subclassing".

If non-standard behavior is not required, then subclassing it never normally required in an application.

It is also possible to create a new "class" of control by taking an existing control and creating a new class based on it's behavior - this is known as "superclassing" and offers a powerful way to create custom controls.

Superclassing and subclassing are advanced topics - they will cause more confusion than clarification to anyone that is unfamiliar with widnows classes and messaging, message queues, etc.

For extensive guidelines on any of the topics in this thread, we highly recommend a good Windows programming book! See the FAQ forum for recommended titles.



------------------
Lance
PowerBASIC Support
mailto:[email protected][email protected]</A>