Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations TouchToneTommy on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

Terminating An Application - Modeless Dialogs

Status
Not open for further replies.

sweep123

Technical User
May 1, 2003
185
GB
What is the best way to terminate an application which may have several modeless dialog windows on display. Would like to just click a button on the main modal dialog window to terminate the application and close all the modeless dialogue windows with out any errors.

Sweep.
 
call EndDialog for each dialog window you have.

Ion Filipski
1c.bmp

ICQ: 95034075
AIM: IonFilipski
filipski@excite.com
 
EndDialog is for modal dialogs, not modeless ones.

Do you actually get any errors when closing the app?

Anyway, call DestroyWindow for each modeless dialog you wish to close.



/Per

if (typos) cout << &quot;My fingers are faster than my brain. Sorry for the typos.&quot;;
 
If you have dialog members that you have created dynamically using NEW then you need to use DELETE to remove them unless you will get memory leaks.

However, as long as the dialogs were not created in their own thread, terminating the main thread should close all the windows.

Are you getting some other behavior?
 
Question:
>> What is the best way to terminate an application
Reply:
>> unless you will get memory leaks.

Yeah... cause those memory leaks in your terminated application can cause it to terminate. That results in an endless termination loop until it sucks the entire universe into it. Now you don't want to be responsible for the destruction of the universe do you?

-pete
 
The main application kicks off a thread to receive UDP datastreams. The data received is displayed (after some processing), on various modeless dialog windows.
Now the user may close and reopen these modeless dialog windows, however when the user wishes to terminate the application, via a push button on the main modal dialog window, this is my problem.

I get an Assertion error, not tracked it down yet, but now starting to put code in to:-
1. terminate the UDP Reading thread
2. Turn off the updating of these modeless dialogs when they are closed (set the pointer to NULL and delete the 'this' when closed).

But still getting the error, so looking for a way to terminate the task and do the housekeeping.

Sweep.
 

It sounds like this is what you're doing:

Receiving data and updating the dialogs from your receive thread if any dlgs are open using a pointer to each dlg. Only problem is you terminate the app and the receive thread terminates last and still trys to update a dlg that has been destroyed but it's pointer is not nulled so it asserts.

Here's what you should be doing:

The recieve thread queues the data as is comes in or stores it in a CDocument class. Each dlg has a timer, part of the CDialog class. Use this timer in each dialog to update thier dispaly say every 100mS buy reading the data in the queque or CDocument class. This way the dialog takes care of it's own updating.

It is more work at first but the good thing about doing it this way is you can create more views or dlgs and never need to mess with the recieve thread code again. Just add code for the updating of the new view or dlg. Your receive thread code is more portable too.

So main app:

OnStartUp()
- create queue
- create recieve thread (pass in pointer to queue to store data)
- create dlgs (pass in pointer to queue to read data)
- display dlgs

OnTerminateApp()
- destroy dlgs
- terminate thread
- close app


Brother C
 
I did think of doing that but decided to seek a solution within the current scheme.
But as you have pointed it out, then I think I will implement that scheme.

Just was trying to tie the display updates with the rate that the data was received, currently 5 times a second.

So timers with a resolution of 200msec should be OK.

Its just sometimes the accuracy of timers is a bit worrying, say less than 50 msec.

Sweep
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top