|
|
|
how to create a modeless dialog in VC++
|
Original Message
|
Name: Alex G.
Date: August 19, 2002 at 14:47:24 Pacific
Subject: how to create a modeless dialog in VC++
|
Comment: Hello, I would like to create a modeless dialog using MS visual C++ 6.0. I already implemented a modal dialog, but it's sort of annoying to close it every time to switch focus to my main dialog. In the dialog i display some images that are constantly changing. Instead of a modal i would like to use modeless dialog so i can have it hanging on the background while i can play with my main dialog (i have some buttons there). How can i do this? Thanks in advance, Alex
Report Offensive Message For Removal
|
|
Response Number 1
|
Name: Jeff J
Date: August 20, 2002 at 07:30:43 Pacific
|
Reply: (edit)That depends on how you created your dialog. If you used the resource editor and wizard to generate a class based on CDialog, then you need to call .Create() instead of .DoModal() to invoke it as modeless. If you used the API, then you need to create the dialog using CreateDialog() instead of DialogBox(). Cheers
Report Offensive Follow Up For Removal
|
|
Response Number 2
|
Name: Alex G.
Date: August 20, 2002 at 07:41:39 Pacific
|
Reply: (edit)Jeff, I actually got the modeless dialog to work(using the resource editor+ call to Create()); however i don't know where i should call DestroyWindow() and set my window pointer to NULL. I have a close button in modeless dialog and if i press it the window closes fine, but i know i am leaking memory someplace. Do you have any suggestions here? Thanks, Alex G.
Report Offensive Follow Up For Removal
|
|
Response Number 3
|
Name: Jeff J
Date: August 20, 2002 at 11:46:23 Pacific
|
Reply: (edit)You just need to override the message handler associated with the close button. I'll assume here that it's OnCancel, rather than OnOK, but this idea will work with either one: class CYourDlg : public CDialog { public: void OnCancel() { DestroyWindow(); }; //rest of code... }; This will prevent CDialog's default OnCancel handler (or OnOK if that's the case) from calling EndDialog, which is causing your leak. Obviously, I don't know the name of your dialog class, so i just called it CYourDlg here. You can also tidy up other resources you need to in that handler. If the button is firing some other handler, just make sure that ultimately DestroyWindow is being called, and not EndDialog.
Report Offensive Follow Up For Removal
|
|
Response Number 4
|
Name: Alex G.
Date: August 22, 2002 at 09:56:26 Pacific
|
Reply: (edit)Jeff, thanks for your help. Have another simple question. What message windows generate once you click on the upper right corner(i'm talking about a close button) of the dialog? The reason i ask is that when disposing of the dialog by clicking "Close" button, ONOK fires and there i call DisposeWindow(), so m_hWnd member gets set to NULL. However, when click on the upper right corner of dialog, the m_hWnd member is not NULL, which tells me that the window still exists. Thanks much, Alex G.
Report Offensive Follow Up For Removal
|
|
Response Number 5
|
Name: Jeff J
Date: August 22, 2002 at 20:40:05 Pacific
|
Reply: (edit)The processing of the close button in the corner of a dialog is a little different than for regular windows. Actually, it all starts out the same (with WM_CLOSE being generated and whatnot), but Windows turns that into a WM_COMMAND message for the Cancel button in the dialog. By convention, the Cancel button on a dialog causes IDCANCEL to be sent with a WM_COMMAND message (along with the BN_CLICKED notification), whereas an OK button sends IDOK with a WM_COMMAND message. In the MFC, when these messages are caught, they fire the OnCancel and OnOK handlers, respectively. Ultimately, clicking Cancel (if your dialog has such a button), the little X in the corner, or pressing ESC, all fire the OnCancel handler. Since your Close button is wired to the OnOK handler (which catches IDOK), the default OnCancel handler is still calling EndDialog. Thus, you need to override OnCancel in the same way as you did with OnOK. Those should be the only two handlers that would normally call EndDialog. Nice thoroughness. Such carefulness is the kind of thing everyone appreciates during the debug phase :) Cheers
Report Offensive Follow Up For Removal
|
Use following form to reply to current message:
|
|

|