• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: NSApplication terminate: behavior
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: NSApplication terminate: behavior


  • Subject: Re: NSApplication terminate: behavior
  • From: Andreas Färber <email@hidden>
  • Date: Fri, 20 Jan 2006 21:12:39 +0100

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. ;-)


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.


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.

Regards,

Andreas

P.S. Callling my System.Environment.Exit() from the atexit() callback btw shows some unexpected output and ultimately crashes, thus is not usable.
_______________________________________________
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
  • Follow-Ups:
    • Re: NSApplication terminate: behavior
      • From: Camillo Lugaresi <email@hidden>
References: 
 >NSApplication terminate: behavior (From: Andreas Färber <email@hidden>)
 >Re: NSApplication terminate: behavior (From: Camillo Lugaresi <email@hidden>)

  • Prev by Date: Re: Universal Binary Problem (Carbon Issue?)
  • Next by Date: MFC Porting Issues
  • Previous by thread: Re: NSApplication terminate: behavior
  • Next by thread: Re: NSApplication terminate: behavior
  • Index(es):
    • Date
    • Thread