Re: NSApplication terminate: behavior
Re: NSApplication terminate: behavior
- Subject: Re: NSApplication terminate: behavior
- From: Camillo Lugaresi <email@hidden>
- Date: Fri, 20 Jan 2006 22:15:38 +0100
On 20/gen/06, at 21:12, Andreas Färber wrote:
Hello Camillo,
On 20/gen/06, at 02:26, Andreas Färber wrote:
I have noticed that NSApplication's run method does not return
and call exit() instead. Posts on this list and other places
suggest to do cleanup in applicationWillTerminate: or an atexit()-
registered callback function. However this does not do what I
want it to...
The native Objective-C run method is being called from a managed
context and the ObjC runtime / AppKit framework exiting the app
does not let Garbage Collection happen for the managed context.
If from a managed context I just call the CLR exit() equivalent
System.Environment.Exit(0), it does a GC run but does not return
to my Main method either, and the menu item stays selected and my
window visible for some seconds after the application is Exit'ed.
Calling stop: from applicationShouldTerminate:
returning ...Cancel returns from run to Main but just as Exit()
the Cocoa termination cleanup is not performed correctly.
And when I throw an Exception in the atexit handler it does not
go back through the callstack, probably because all native
instances are already dealloc'ed...
So is there some geeky way to write a run equivalent that does
not exit but instead return?
The problem is not with run: you can break out of it by calling
stop. It's terminate that calls exit. What you should do is call
stop instead of terminate, and reproduce the functionality of
terminate after run exits, by calling delegate methods as outlined
in the documentation.
Well from my view the problem is run not returning as I am not
calling terminate: myself. ;-)
You mean you are not in control of the Cocoa application?
I did try calling stop: from applicationShouldTerminate: returning
NS***Cancel and, like I said in the above quote, it worked in
taking me back to my Main method. However I did not find an easy
way to terminate (as opposed to "terminate:") the Cocoa
NSApplication, leaving the windows, application menu etc. on screen
until after my main application was already exited.
I think stop just sets a flag that tells run to stop looping; if you
call it in applicationShouldTerminate, you're already inside
terminate and exit is going to be called anyway. You need to prevent
terminate from being called, or replace the default implementation
with something that calls stop instead.
What does terminate: do exactly anyway apart from calling the
delegates? Any docs on that part?
What exactly is not working for you, once you call all delegate
methods correctly?
Maybe I do not understand the concept of Cocoa delegates correctly?
I myself have set up for testing purposes an object using
setDelegate: on which to receive the applicationShould/
WillTerminate: messages. Why should I send those messages to myself
from my own Main? Would sending such messages also hide and release
my windows as a nice side-effect?!
If I knew what exactly terminate: was doing *apart from calling my
delegates* - the latter being well documented, I know, I've read it
or I would not be receiving them :-) - then I could send those
messages myself, whether manually from my Main method or maybe
implicitly by posing as NSApplication.
Are you saying that you already implemented everything the
documentation says (calling app delegate methods, document-based app
methods, sending the notification, all in the right order), and
things still aren't getting cleaned up correctly?
There's also the possibility that it's not a Cocoa problem at all.
For example, AppKit might not be destroying windows when the app
quit, instead relying on a lower layer mechanism (such as an atexit
callback that tells the window server that the app is going down, so
it can destroy all of its windows?).
However, the important application-specific cleanup is done inside
delegate methods. As long as you're calling them as stated in the
documentation, documents will be closed, preferences will be saved, etc.
Camillo _______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden