• 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: Running Launch Chores, before document open Was: Modal Dialog … Crash
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Running Launch Chores, before document open Was: Modal Dialog … Crash


  • Subject: Re: Running Launch Chores, before document open Was: Modal Dialog … Crash
  • From: Jerry Krinock <email@hidden>
  • Date: Thu, 16 Sep 2010 14:59:49 -0700

Agreed; I don't like the idea of having to ensure that no "GUI Things" or "AppKit Stuff" would ever be done in anything I might invoke from -applicationWillFinishLaunching.  I could easily forget this, or accidentally invoke someone else's code that might decide to, say, display an error dialog once in awhile.

So…

On 2010 Sep 15, at 19:49, Lee Ann Rucker wrote:

> But for catching the case where your app is launched by a double-click, what you want is application:openFile: or application:openFiles:

Wow.  Another useful method which has been around since 10.0 which I'd never heard of.  So the solution is to run my "early launch chores" in both -application:openFiles: *and* in -applicationDidFinishLaunching:, with a little flag as Kyle suggested, to make sure they run only once in the event that the app is launched by doubleclicking a document.

> The runloop is live at this point, because our app shows some UI at that point.

Verified.  If I display a modal dialog in -application:openFiles: and then start a modal session in -applicationDidFinishLaunching:, there is no crash.

It's odd that Apple doesn't provide a method which always runs, and after the app is GUI-safe, but always before any document opens.

Anyhow, still without a concise definition of "GUI Stuff" or "AppKit things", I submitted Document Feedback on -applicationWillFinishLaunching:.

---------------------------------------------


- (void)doFinishLaunchingEarlyChores {
    // Your Early Chores Here…
    …
    // This code will always run once, and always
    // run before any document is opened.
}

- (BOOL)application:(NSApplication*)app
           openFile:(NSString*)filename {
    [self doFinishLaunchingEarlyChores] ;
    m_didFinishLaunchingEarlyChores = YES ;
    return NO ; // Defer document opening to usual methods
}

- (void)applicationDidFinishLaunching:(NSNotification *)aNotification {
    if (!m_didFinishLaunchingEarlyChores) {
        [self doFinishLaunchingEarlyChores] ;
    }

    // Your Later Chores Here…
    …
    // If app is launched by doubleclicking a document,
    // this code will run *after* the document is opened.


_______________________________________________

Cocoa-dev mailing list (email@hidden)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:

This email sent to email@hidden

References: 
 >Very Simple Demo: Modal Dialog causes later Modal Session to Crash (From: Jerry Krinock <email@hidden>)
 >Re: Very Simple Demo: Modal Dialog causes later Modal Session to Crash (From: Kyle Sluder <email@hidden>)
 >Re: Very Simple Demo: Modal Dialog causes later Modal Session to Crash (From: Jerry Krinock <email@hidden>)
 >Re: Very Simple Demo: Modal Dialog causes later Modal Session to Crash (From: Kyle Sluder <email@hidden>)
 >Re: Very Simple Demo: Modal Dialog causes later Modal Session to Crash (From: Lee Ann Rucker <email@hidden>)

  • Prev by Date: Re: Foundation level object leaks
  • Next by Date: Re: bindings and NSNumberFormatter, enforcing min/max values
  • Previous by thread: Re: Very Simple Demo: Modal Dialog causes later Modal Session to Crash
  • Next by thread: keyDown:theEvent
  • Index(es):
    • Date
    • Thread