What does the DDT engine do with messages?

[Gary Beene]

In Help, I see this sentence often, referring to what happens if a Callback is not provided in the PowerBASIC app.

Otherwise, the DDT engine processes unhandled messages.

I understand what it means in general, but are the details of what happens available? Should I care?

My first guess is that the DDT engine takes no action, other than to tell the OS that the PowerBASIC app handled the message and that no further action is required. But that sounds too simplistic an answer, so I doubt I'm right.

If the answer is different for each message, I don't need the details. I'm just looking for a generic answer.

Does anyone know more?

[Michael Mattias]

For unhandled messages it "generally" takes the Windows default action for that message.

Note that many messages are in fact "notification only" and you could not do anything anyway.

Yes, it varies from message to message.

eg, WM_COMMAND is a "notification" message.. there's nothing you can do about it and nothing Windows can do with it.

However, some of the WM_NOTIFY messages expect a response; eg, if a listview control sends WM_NOTIFY/NM_CUSTOMDRAW, you may respond to it by telling windows to do something special, or do nothing with it, in which case Windows will just perform the default action, which is to "draw the item normally with respect for selected and focused status."

[John Petty]

I shouldn't be replying as MCM is much more knowledgable that me in this area but my understanding is that there is little difference between DDT and SDK in that if the message is not handled by the program it is passed on to a default processor which is one of MS's best kept secrets.

[Michael Mattias]

It's not a secret at all. Dialogs work with the DefDlgProc function, windows with the DefWindowProc function. Both are documented. Either may be called by the using program, although it would be rare to call DefDlgProc explicitly, unless you have created your own superclass of the basic dialog procedure and created the window with CreateWindowEx.... which if course means you are now WAAAAY off the "DDT" reservation.

What is a (trade) secret is what PB does with various messages. We can only guess, but I'll bet an awful lot of these guesses are correct.

However, what PB does with those messages is immaterial, as PB is only responsible for the documented behavior of its intrinsic commands; how they do it is immaterial to us, and because it is proprietary it is subject to change without notice.

MCM

[John Petty]

MCM
Like I said your area of expertise not mine but I can't find any descrptions of the default actions that either of those API's do, ie DefWindowProc is defined as follows "The DefWindowProc function calls the default window procedure to provide default processing for any window messages that an application does not process. This function ensures that every message is processed. DefWindowProc is called with the same parameters received by the window procedure. " but doesn't tell me what those default actions are, ie you recently posted a question about selection of text in a combobox where it would appear (given my lack of knowledge) that the default action upon setting focus was to select all text. Did you find where MS documented that?
Why complain about PB, it has to rely on the same documentation.
John

[Michael Mattias]

that the default action upon setting focus was to select all text. Did you find where MS documented that?

It's in the doc for edit controls, "default message processing", WM_SETFOCUS.

Why complain about PB, it has to rely on the same documentation.

Who's complaining? I merely said what PB does with messages not handled in a CALLBACK FUNCTION are really not the user's concern, because PB is responsible for the behavior (aka the "what") of its "DDT-created" dialogs; the method used to obtain that behavior (aka the "how") is immaterial.

If PB chooses to rely on the Windows documentation to create the desired behavior, fine. But regardless of the accuracy or inaccuracy of that documentation, PB is still responsible for the behavior it promises.

MCM