Re: NSApplication terminate: behavior
Re: NSApplication terminate: behavior
- Subject: Re: NSApplication terminate: behavior
- From: Andreas Färber <email@hidden>
- Date: Fri, 20 Jan 2006 23:23:01 +0100
Am 20.01.2006 um 22:15 schrieb Camillo Lugaresi:
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?
What I mean is this: My bundle starts up the Mono executable via a
launch script and symlink and loads my application. My class library
then calls NSApplicationLoad() to load AppKit as a dynamic library
sort-of, loads the menu from a nib and sets up the main window; when I
am done with initializing I call [[NSApplication sharedApplication]
run]. I then at some point quit the application via the menu command in
the application menu (or its shortcut). I do not have control over Mono
shutdown.
Because of the circumstance that Cocoa was not started up as a native
application, whenever the application decides to exit I would wish to
have it return control back to the application that loaded it so that
it can shut down gracefully. My managed code is for instance using
notification web services as part of an object model that would need to
be unregistered before the app terminates and its sockets "disappear";
this is not really exposed in the object model and shouldn't be and
works fine on Windows with the objects being finalized.
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,
a) If in ***shouldTerminate I return ***Cancel
(NSApplicationTerminateReplyCancel?) it does not terminate;
b ) if I return *Now it terminates immediately, not returning to Main
as usual, and
c) if I return *Later the main loop is halted, not returning to Main.
If I call stop: before I return Cancel, I get out of the run loop and
back to Main but the application is still alive, just no runloop
active.
or replace the default implementation with something that calls stop
instead.
I guess I would be able call stop: from a posed-as terminate: method
but I would have to know what to do there. :-(
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.
Could you please explain this further? What delegates exactly are you
referring to? The AppKit NSApplication documentation says this about
terminate:
<<This method is typically invoked when the user chooses Quit or Exit
from the application’s menu. Each use of terminate: invokes
applicationShouldTerminate: (page 144) to notify the delegate that the
application will terminate. If applicationShouldTerminate: (page 144)
returns NO, control is returned to the main event loop, and the
application isn’t terminated. Otherwise, the document controller of the
application (if one exists) is asked to check its documents and, if
there are unsaved changes, ask the user to save those changes. Then,
this method posts an NSApplicationWillTerminateNotification (page 147)
to the default notification center. Don’t put final cleanup code in
your application’s main() function—it will never be executed. If
cleanup is necessary, have the delegate respond to
applicationWillTerminate: (page 145) and performcleanup in that method.
>>
The YES or NO is actually replaced by the three enum values referenced
somewhere above, as specified in the delegates' documentation.
Now are these the two delegates that you say I should call myself?
Don't they just enable *me* to react to these events? And how exactly
would I invoke them anyway?
Right now when experimenting with stop: I do not know what exactly to
do from there! That's one of the questions. The documentation does not
say "call this, do that", the above quote and other places just
describe that terminate: is calling the two mentioned delegates, but
does not say anything else it might be doing.
And to make it very clear I do not want to call anything from my Main
method that again would result in a call to exit() on the side of
Cocoa. Just close and release the windows, views, controls, menu and
let me return to my NSAutoreleasePool wrapper and other managed
non-Cocoa objects.
Thanks for your help,
Andreas
_______________________________________________
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