Re: Closing modeless dialogs

Hi Torsten,

I think the main thing to watch out for is that the routine that started your dialog does not exit. For example, if you open a modeless dialog where the object is created on the stack, then return from the function, you will get errors. However, if you are just looping in the routine and using the dialog to display information during the loop I can't see where you would have a problem.

If I wanted a modeless dialog to stay open for the life of my application I would make the dialog object a member of my mainframe class and create functions there (in mainframe) to start, show, hide, and end the dialog.

Tom

"Torsten Hensel" <Hensz@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message news:1205316527.05@xxxxxxxxxxxxxxxxxxxxx
Joseph M. Newcomer wrote:

Modeless dialogs are one of the places where you typically have to
actually allocate on the heap.

What's the reason for this? I need to display a dialog, do something while the dialog is displayed, then close the dialog and dismiss the object. I don't see a problem here with allocating the object on the stack.

Creating one during InitInstance is a bit dangerous, because the
message pump is not yet working.

I think I understand this problem. But how can I achieve what I want without creating the dialog in InitInstance? Ok, some more explanations:

I created a dialog based application in VisualStudio just to get the simplest possible MFC application. I only want to display a dialog (simply showing something like "Please wait"), then call two functions, finally close the dialog and end the application. So the dialog does not need to exist after InitInstance is done.

The only place that I know where to place my entire code is InitInstance or ExitInstance. What are the alternatives?

I know that what I'm doing here is not the best solution for MFC programming: the dialog is not updated. But this is no issue here, I just need a very simple display that something is happening. The operation will only take a few seconds at most. So creating a worker thread to perform the operation and creating the dialog somewhere else is overkill for this problem.

As already pointed out, you don't use OnOK to close a modeless dialog;
in fact, you have
to override it and remove its body, as you also have to do for OnCancel.

I've done that already - to prevent closing the dialog with ESC and Enter.

If you get assertions, your program is wrong, and you have to fix it.
But note that what
you are showing here is a compiler warning;

No, this is a TRACE output during runtime.

you have not said what the assertion is, what
file it occurs in, what line it is on, and what version of VS you
are using.

This is true ;-)
I would post this information if I could reproduce the issue. But today everything is working fine. No warnings, no assertions, and I didn't change anything in my code. Perhaps something was wrong with my Windows yesterday (my system behaved quite strange, reacted slowly and some applications crashed without reason)?

The assertion occurred somewhere inside an MFC file, like wincore.h or cpp. I remember the line number: 1007.

Now my dialog class has the following functions:
- a virtual destructor with if (m_hWnd) DestroyWindow();
- a CloseWindow function with if (m_hWnd) DestroyWindow();
- virtual OnCancel and OnOK, both empty
- standard constructor and OnInitDialog

I create the dialog with Create(IDD_...) and ShowWindow(SW_SHOW), and I close the dialog either by calling CloseWindow or by deleting the dialog object (when leaving scope). And this works for today - let's see if it still works tomorrow...

Best regards, and thanks for all the replys!
Torsten

On Tue, 11 Mar 2008 16:52:46 +0100, Torsten Hensel wrote:
I created a simple dialog-based application. Then I created a modeless dialog in MyApp::InitInstance - the dialog object is created on the stack. Displaying the dialog works (I call Create() first and then ShowWindow(SW_SHOW)). But when I close the dialog using either DestroyWindow() or CDialog::OnOK() I get the following warning (and assertions):
Warning: calling DestroyWindow in CDialog::~CDialog --
OnDestroy or PostNcDestroy in derived class will not be called.
Warning: calling DestroyWindow in CWnd::~CWnd; OnDestroy or PostNcDestroy in derived class will not be called.

Btw. when I use OnOK I get only two assertions, with DestroyWindow I get three.

I searched for those warnings in google, and I searched for modeless dialogs in general. The only thing I found was to implement the PostNcDestroy function with delete this; But this should only be necessary when creating the dialog object on the heap...

What can I do to prevent this warning? I don't have any idea!


.

Relevant Pages

  • Re: Closing modeless dialogs
    ... I only want to display a dialog, then call two functions, finally close the dialog and end the application. ... No warnings, no assertions, and I didn't change anything in my code. ... Perhaps something was wrong with my Windows yesterday (my system behaved quite strange, reacted slowly and some applications crashed without reason)? ... But when I close the dialog using either DestroyWindowor CDialog::OnOKI get the following warning: ...
    (microsoft.public.vc.mfc)
  • Re: Closing modeless dialogs
    ... Modeless dialogs are one of the places where you typically have to actually allocate on ... As already pointed out, you don't use OnOK to close a modeless dialog; ... If you get assertions, your program is wrong, and you have to fix it. ... DestroyWindowor CDialog::OnOKI get the following warning (and ...
    (microsoft.public.vc.mfc)
  • Re: Help sought re vbmodeless form rendering a class module useless
    ... the class module. ... I meant display the Userform modelessly when you first call it! ... For Each ctl In UserForm4.Controls ... any longer once it is modeless. ...
    (microsoft.public.excel.programming)
  • Re: Help sought re vbmodeless form rendering a class module useless
    ... the class module. ... I meant display the Userform modelessly when you first call it! ... For Each ctl In UserForm4.Controls ... As far as I know there is no different between non modal and modeless ...
    (microsoft.public.excel.programming)
  • Re: Help sought re vbmodeless form rendering a class module useless
    ... Private Sub ModeChange_Click ... I still do not understand why you do not display the Userform ... My code revolving around the class module that is impacted is as follows: ... longer once it is modeless. ...
    (microsoft.public.excel.programming)