I've found an app which calls DialogBoxParam, but destroys the dialog from inside WM_INITDIALOG, yet expects the dialog to still be alive until WM_INITDIALOG processing is done, i.e.
case WM_INITDIALOG: ... initialize and write values to lots of controls ...
if (user_dont_want_to_see_this_dialog_today) { DestroyWindow(hDlg);
... mess some more with controls (like reading their current values) ...
return; }
Does anyone have a good way to deal with this? One way might be to make DestroyWindow map to EndDialog in this case (as EndDialog manages to handle this right), but what would the best way to do that be?
Ove Kaaven ovehk@ping.uio.no writes:
Does anyone have a good way to deal with this? One way might be to make DestroyWindow map to EndDialog in this case (as EndDialog manages to handle this right), but what would the best way to do that be?
You should probably write a test program under Windows to check that, but I would be quite surprised if DestroyWindow didn't destroy the window. What is causing the app to break? Do we fail to check for valid window handles somewhere?
On 3 Nov 2002, Alexandre Julliard wrote:
Ove Kaaven ovehk@ping.uio.no writes:
Does anyone have a good way to deal with this? One way might be to make DestroyWindow map to EndDialog in this case (as EndDialog manages to handle this right), but what would the best way to do that be?
You should probably write a test program under Windows to check that, but I would be quite surprised if DestroyWindow didn't destroy the window. What is causing the app to break? Do we fail to check for valid window handles somewhere?
Well, the heap gets corrupted. But I can try to take another look soon.
-
Alexandre Julliard -
Ove Kaaven