One last Callback Question

[Brad D Byrne]

Good reminder ---

And, --- not that I really want to tackle the order right now---

I have read somewhere that Windows Does stack "some" of the messages

in a hirarchy. Borge I think what I'm really trying to grasp right

now ----- is the order of the Dialog/Control structure -----

ie.-- obviously; (I think), A "Button" is a special "Label" and a

"Label" is a special "Line"Cntrl, etc.... This may seem trivial but

I believe that it is best and eventually easiest to let Windows handle

all the Painting, I believe this can be done w/o any sub-classing

by Blitting to the Dialogs from with-in the Callback functions---

which will allow our new "Custom Control" to inhierit all the Window

properties, documented or not.

Food for thought or confusion---- I don't know????

But anyway its helping me learn this enviornment.....B



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

[Borje Hagsten]

One important thing to remember: One can never trust the message's order
in Windows. In this case, I think it's pretty safe to assume WM_INITDIALOG
will be first message though, since it is the DDT engine that controls the
callback, but when using SDK style windows and standard WinProc, sometimes
the message order can be completely out of order. Like the Bible says,
"Windows moves in mysterious ways" ..


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

[Brad D Byrne]

Thanks, Borge

Good idea w/ the message box test - one I should have thought of!

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

[Borje Hagsten]

I think DDT callback is first invoked at %WM_INITDIALOG, which happens
on DIALOG SHOW. Easy to test - place a MSGBOX right before DIALOG SHOW
and add a BEEP statement at the top of the dialog's callback procedure.
The MSGBOX will be shown before the beep..

As far as I know, with modal DDT dialog you can't reach inside DDT's own
message loop. Question is what you need? The DDT engine has a life of its
own - it passes on most messages, but swallows some. In most cases the
messages passed on to the callback are enough and for those that aren't,
there usually is some API call one can use, for example in WM_TIMER.

------------------
Maybe should add that WM_TIMER must be set via SetTimer API, and then
reset in for example WM_DESTROY with KillTimer API. Several samples in
source code forum on how to do it.


[This message has been edited by Borje Hagsten (edited September 18, 2001).]

[Brad D Byrne]

Question copied from previous post:


Is 1) the Callback function only envoked upon call,
or, 2) does it start running upon creation ?

If;
1) can you trap the messages before destroyed?

2) can you access it's messages from outside the
Callback function?

Thanks, B



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