WM_INITDIALOG *not* being called First!?

[win2k user]

I was adding some XP flavor to my app so I can get double buffering on my
listviews, and what I found out is if I have the manifest file in the
directory with the program, it crashes. Without it, it don't.

So I then try to debug the sucker and noticed that WM_INITDIALOG does *NOT*
get called first!
WM_NOTIFY and WM_COMMAND are being called first, and crashing.

Can anyone tell me why windows is doing this? I thought WM_INITDIALOG is
supposed to ALWAYS be called first! It *IS* always called first without the
manifest file though.

I am not using any windows per se, just a Dialog to do all my work.

I then added some code to basically check if WM_INITDIALOG is called, and if
not, I return TRUE. What do you know, now my app works fine with all the XP
flavored features. I just can't understand WHY it is doing this!

Anyone shed some light on this?

[Alexander Grigoriev]

Do you see anywhere in the documentation that WM_INITDIALOG is guaranteed to
call before all other?

Actually, I suspect you're using MFC and the dialog gets subclassed very
early. WM_INITDIALOG may be the first to go to DialogProc, but definitely
not the first to go to WindowProc. As the controls get created, the
notifications may be sent to the dialog.

Post by win2k user
I was adding some XP flavor to my app so I can get double buffering on my
listviews, and what I found out is if I have the manifest file in the
directory with the program, it crashes. Without it, it don't.
So I then try to debug the sucker and noticed that WM_INITDIALOG does *NOT*
get called first!
WM_NOTIFY and WM_COMMAND are being called first, and crashing.
Can anyone tell me why windows is doing this? I thought WM_INITDIALOG is
supposed to ALWAYS be called first! It *IS* always called first without the
manifest file though.
I am not using any windows per se, just a Dialog to do all my work.
I then added some code to basically check if WM_INITDIALOG is called, and if
not, I return TRUE. What do you know, now my app works fine with all the XP
flavored features. I just can't understand WHY it is doing this!
Anyone shed some light on this?

[win2k user]

While that is true, it would make sense that a INIT process gets called
before everything else does it not?
And no, not using MFC, pure win32.
That also don't explain what does the manifest actually do, it is obviously
sending to the other WM_ messages, but *why*.
Wish MS would document better!


Oh, forgot to say my e-mail is broken. :(

Post by Alexander Grigoriev
Do you see anywhere in the documentation that WM_INITDIALOG is guaranteed to
call before all other?
Actually, I suspect you're using MFC and the dialog gets subclassed very
early. WM_INITDIALOG may be the first to go to DialogProc, but definitely
not the first to go to WindowProc. As the controls get created, the
notifications may be sent to the dialog.

Post by win2k user
I was adding some XP flavor to my app so I can get double buffering on my
listviews, and what I found out is if I have the manifest file in the
directory with the program, it crashes. Without it, it don't.
So I then try to debug the sucker and noticed that WM_INITDIALOG does

*NOT*

Post by win2k user
get called first!
WM_NOTIFY and WM_COMMAND are being called first, and crashing.
Can anyone tell me why windows is doing this? I thought WM_INITDIALOG is
supposed to ALWAYS be called first! It *IS* always called first without

the

Post by win2k user
manifest file though.
I am not using any windows per se, just a Dialog to do all my work.
I then added some code to basically check if WM_INITDIALOG is called,

and

Post by Alexander Grigoriev
if

Post by win2k user
not, I return TRUE. What do you know, now my app works fine with all the

XP

Post by win2k user
flavored features. I just can't understand WHY it is doing this!
Anyone shed some light on this?

[Jason]

The WM_INITDIALOG message is sent to the dialog box procedure immediately
before a dialog box is displayed. Dialog box procedures typically use this
message to initialize controls and carry out any other initialization tasks
that affect the appearance of the dialog box.

A lot can happen before your window is ready to be dispayed... seems pretty
simple to me...Unfortunatly windows is a multithreaded system and you cant
write code assuming everything will happening linearly and exactly the same
in all cases. Maybe check if the window is visible or have a bInitialize
flag before trying to process stuff.

Jason

Post by win2k user
While that is true, it would make sense that a INIT process gets called
before everything else does it not?
And no, not using MFC, pure win32.
That also don't explain what does the manifest actually do, it is obviously
sending to the other WM_ messages, but *why*.
Wish MS would document better!
Oh, forgot to say my e-mail is broken. :(

Post by Alexander Grigoriev
Do you see anywhere in the documentation that WM_INITDIALOG is

guaranteed

Post by win2k user
to

Post by Alexander Grigoriev
call before all other?
Actually, I suspect you're using MFC and the dialog gets subclassed very
early. WM_INITDIALOG may be the first to go to DialogProc, but definitely
not the first to go to WindowProc. As the controls get created, the
notifications may be sent to the dialog.

Post by win2k user
I was adding some XP flavor to my app so I can get double buffering on

my

Post by Alexander Grigoriev

Post by win2k user
listviews, and what I found out is if I have the manifest file in the
directory with the program, it crashes. Without it, it don't.
So I then try to debug the sucker and noticed that WM_INITDIALOG does

*NOT*

Post by win2k user
get called first!
WM_NOTIFY and WM_COMMAND are being called first, and crashing.
Can anyone tell me why windows is doing this? I thought WM_INITDIALOG is
supposed to ALWAYS be called first! It *IS* always called first without

the

Post by win2k user
manifest file though.
I am not using any windows per se, just a Dialog to do all my work.
I then added some code to basically check if WM_INITDIALOG is called,

and

Post by Alexander Grigoriev
if

Post by win2k user
not, I return TRUE. What do you know, now my app works fine with all the

XP

Post by win2k user
flavored features. I just can't understand WHY it is doing this!
Anyone shed some light on this?