XPert
asked on
EndDialog does not end the dialog
Hello Experts,
I have some simple code which I have complicated by using some ShellNotify, etc. Here is the logic:
I display the dialog using DoModal.
In the dialog I call ShellNotify to create a Tray Icon (the small thingies that run next to the clock). After installing the tray icon the code is hiding the dialog: ShowWindow(SW_HIDE). All this is standard practice for the creating a tray icon.
In the click event for the tray icon I display a menu which has "Exit" as one of the options.
In the handler code for the exit menu item click event I call EndDialog to end the dialog box. You'd expect DoModal to return with the exit value. It does not.
I understand from the MSDN documentation, and I quote, "EndDialog does not close the dialog box immediately. Instead, it sets a flag that directs the dialog box to close as soon as the current message handler returns."
Couple of things you need to know. I am setting off some timers using SetTimer for doing some periodic monitoring work which I am killing using KillTimer. When the timer expires I use CSocket to communicate with some servers over the network. Basically the app is a monitoring tool.
How do I make the "current message handler return" (from where?)? Is there a way to flush out all the messages and make the dialog exit gracefully and my app to exit gracefully ... or just say forget those freaking message and exit already :)
The problem is that the app continues to execute in the background even after the tray is cleared and the dialog is not to be seen. I have to use task manager to kill it.
XPert.
I have some simple code which I have complicated by using some ShellNotify, etc. Here is the logic:
I display the dialog using DoModal.
In the dialog I call ShellNotify to create a Tray Icon (the small thingies that run next to the clock). After installing the tray icon the code is hiding the dialog: ShowWindow(SW_HIDE). All this is standard practice for the creating a tray icon.
In the click event for the tray icon I display a menu which has "Exit" as one of the options.
In the handler code for the exit menu item click event I call EndDialog to end the dialog box. You'd expect DoModal to return with the exit value. It does not.
I understand from the MSDN documentation, and I quote, "EndDialog does not close the dialog box immediately. Instead, it sets a flag that directs the dialog box to close as soon as the current message handler returns."
Couple of things you need to know. I am setting off some timers using SetTimer for doing some periodic monitoring work which I am killing using KillTimer. When the timer expires I use CSocket to communicate with some servers over the network. Basically the app is a monitoring tool.
How do I make the "current message handler return" (from where?)? Is there a way to flush out all the messages and make the dialog exit gracefully and my app to exit gracefully ... or just say forget those freaking message and exit already :)
The problem is that the app continues to execute in the background even after the tray is cleared and the dialog is not to be seen. I have to use task manager to kill it.
XPert.
of OnCancel
Some code I think would have been helped more to solve the problem...?
Try ,
EndDialog(IDOK);
DestroyWindow();
EndDialog(IDOK);
DestroyWindow();
Or also,
OnOK();
EndDialog(IDOK);
or
OnCancel();
EndDialog(IDCANCEL);
But I feel like the best solution is the one offered by vbk_bgm !
OnOK();
EndDialog(IDOK);
or
OnCancel();
EndDialog(IDCANCEL);
But I feel like the best solution is the one offered by vbk_bgm !
Btw, the fact your apllication doesn't exit when you call EndDialog shows that something is still "running" in it!
You should verify if everything (Timers, Sockets, etc...) is completely closed and destroyed before call to EndDialog. Well, logically, DestroyWindow() call within the main dlg of your dialog based application should categorically do it for you !
You should verify if everything (Timers, Sockets, etc...) is completely closed and destroyed before call to EndDialog. Well, logically, DestroyWindow() call within the main dlg of your dialog based application should categorically do it for you !
I have pretty much explored all the OnOK() or OnCancel or DestroyWindow() calls and nothing seems to matter.
degarn has hit it right where it hurts. There is something still running or some messages still in the queue. I have made sure that the timers are destroyed and the sockets are closed (though I will double-check that)
I need to know a way to flush out all the messages and exit from the app. A call to exit() function is no good as all of us know. It throws an exception.
I highly appreciate your help in solving this problem. I will still be waiting.
Cheers,
XPert.
degarn has hit it right where it hurts. There is something still running or some messages still in the queue. I have made sure that the timers are destroyed and the sockets are closed (though I will double-check that)
I need to know a way to flush out all the messages and exit from the app. A call to exit() function is no good as all of us know. It throws an exception.
I highly appreciate your help in solving this problem. I will still be waiting.
Cheers,
XPert.
inpras,
I will try and paste some code as my next comment. I had to be on the road in the am period and so haven't yet reached my work desk. I shud be there after noon.
XPert.
I will try and paste some code as my next comment. I had to be on the road in the am period and so haven't yet reached my work desk. I shud be there after noon.
XPert.
ASKER
OOps !!!
I guess I found out the password for my other ID NoXPert. It was on my laptop and I thought I had forgotten it. Well I hope the folks at the Exchange don't get angry at me for using two ids.
So for the last two comments NoXPert == XPert.
Sorry!!!
XPert.
I guess I found out the password for my other ID NoXPert. It was on my laptop and I thought I had forgotten it. Well I hope the folks at the Exchange don't get angry at me for using two ids.
So for the last two comments NoXPert == XPert.
Sorry!!!
XPert.
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
bertp,
You the man, the guru, the expert, the deserving 100 point winner. PostQuitMessage(0) in the red corner wins.
I shall investigate PostQuitMessage further but can the guru, bertp, spare some time and shed some light on PostQuitMessage (the 100 point are yours regardless)
Cheers,
XPert & NoXPert.
You the man, the guru, the expert, the deserving 100 point winner. PostQuitMessage(0) in the red corner wins.
I shall investigate PostQuitMessage further but can the guru, bertp, spare some time and shed some light on PostQuitMessage (the 100 point are yours regardless)
Cheers,
XPert & NoXPert.
Sure,
A UI thread terminates when WM_QUIT is posted to its message queue and of course this is what the PostQuitMessage function does..
DestrowWindow() on your main window should cause this to ultimately happen.. If you find out why it didn't please let me know ;-)
Bert
A UI thread terminates when WM_QUIT is posted to its message queue and of course this is what the PostQuitMessage function does..
DestrowWindow() on your main window should cause this to ultimately happen.. If you find out why it didn't please let me know ;-)
Bert
Instead of calling EndDialog() try and call OnOK()
VinExpert