Win32 Modeless Dialog is being a jerk.

Started by
11 comments, last by BrickInTheWall 14 years ago
Quote:Original post by Programmer16
Quote:Original post by Endurion
A few tiny mistakes:

1)
The main problem: Remove the HWND in your message loop. Pass NULL instead. Otherwise you only process messages of the main window.

2)
Move the return DefWindowProc OUT OF THE DEFAULT CASE AFTER THE SWITCH.

3)
You're calling PostQuitMessage twice, one in the main window close, one in the modeless dialog proc.


Where his DefWindowProc call is shouldn't be a problem. If he handles a message he calls break which falls to return 0. Otherwise, it calls DefWindowProc (for message he doesn't handle.) Unless I missing something.


No, that's correct. I would recommend inverting the logic though and dropping the default case. Have the method return DefWindowProc by default, and the individual cases return (instead of breaking) the appropriate value. This is because not all message types return 0 if the user handles them. Some return other values depending on success or failure.

In time the project grows, the ignorance of its devs it shows, with many a convoluted function, it plunges into deep compunction, the price of failure is high, Washu's mirth is nigh.

Advertisement
Washu said it:

It was a bad decision of MS to fill the default win32 application code (VS) with that return DefWindowProc in the default case (and thus returning 0 on all handled messages). It is luckily correct for the few messages that are used, but once you start adding more handlers you'll stumble upon messages that need a different return value than 0.
Also for quite a few messages that you handle you still have to pass them on to DefWindowProc to get correct behaviour. DefWindowProc is the heart of window behaviour.

There is NO coherent return value that would be valid for all messages.

Edit: Typos

[Edited by - Endurion on April 17, 2010 1:10:22 AM]

Fruny: Ftagn! Ia! Ia! std::time_put_byname! Mglui naflftagn std::codecvt eY'ha-nthlei!,char,mbstate_t>

Quote:Original post by Endurion
A few tiny mistakes:

1)
The main problem: Remove the HWND in your message loop. Pass NULL instead. Otherwise you only process messages of the main window.

2)
Move the return DefWindowProc OUT OF THE DEFAULT CASE AFTER THE SWITCH.

3)
You're calling PostQuitMessage twice, one in the main window close, one in the modeless dialog proc.


Endurion I love you. Turns out it was the message loop that was causing the problem. I can't believe I didn't see this. Passing hWnd basically made the IsDialogMessage check useless.

Thanks to you other guys too for help on other mistakes.

To those saying it's difficult to create a template in memory: It's not, it's just a bit of code you have to get around. There are tutorials for this on MSDN, though I would not recommend their code. In they're article about templates in memory the always talk about how the template header and the controls need to be DWORD aligned and all the data in both of these must be WORD aligned. Alright I thought, no problem, but in they're sample code everything is WORD aligned, and it doesn't work. So anyone also trying this, watch out for the wrong parts in their code, most of it is a good reference though.
I can post the code for creating a template header and a control if anybody is interested.

Thanks for the help,
Brick
Fate fell short this time your smile fades in the summer.

This topic is closed to new replies.

Advertisement