Note that there are some explanatory texts on larger screens.

plurals
  1. PONSDocument saveDocumentWithDelegate deadlocked during App termination
    primarykey
    data
    text
    <p>NSDocument continues to be a software maintenance nightmare.</p> <p>Anyone else having a problem where they want certain blocking dialogs to be handled SYNCHRONOUSLY?</p> <h2>BEGIN EDIT: I <em>may</em> have found a solution that allows me to wait synchronously</h2> <p>Can anyone verify that this would be an "Apple approved" solution?</p> <pre><code>static BOOL sWaitingForDidSaveModally = NO; BOOL gWaitingForDidSaveCallback = NO; // NSDocument dialog calls didSave: when done ... gWaitingForDidSaveCallback = true; [toDocument saveDocumentWithDelegate:self didSaveSelector:@selector(document:didSave:contextInfo:) contextInfo:nil]; if ( gWaitingForDidSaveCallback ) { // first, dispatch any other potential alerts synchronously while ( gWaitingForDidSaveCallback &amp;&amp; [NSApp modalWindow] ) [NSApp runModalForWindow: [NSApp modalWindow]]; if ( gWaitingForDidSaveCallback ) { sWaitingForDidSaveModally = YES; [NSApp runModalForWindow: [NSApp mbWindow]]; // mbWindow is our big (singleton) window sWaitingForDidSaveModally = NO; } } ... - (void)document:(NSDocument *)doc didSave:(BOOL)didSave contextInfo:(void *)contextInfo { [self recordLastSaveURL]; gWaitingForDidSaveCallback = NO; if ( sWaitingForDidSaveModally ) [NSApp stopModal]; } </code></pre> <h2>END EDIT</h2> <p>I have to support Snow Leopard/Lion/ML</p> <p>App termination is an ugly process. When the user decides to quit, and the document has changes that need saving, I call this:</p> <pre><code> gWaitingForDidSaveCallback = true; [toDocument saveDocumentWithDelegate:self didSaveSelector:@selector(document:didSave:contextInfo:) contextInfo:nil]; </code></pre> <p>I <em>really really really</em> want this call to be synchronous, but in latest Lion, this hangs my app: </p> <pre><code> while ( gWaitingForDidSaveCallback ) { // didSave: callback clears sWaitingForDidSaveCallback // do my own synchronous wait for now [[NSRunLoop currentRunLoop] runUntilDate:[NSDate dateWithTimeIntervalSinceReferenceDate:0.05]]; } </code></pre> <p>My best guess for the hang is that the mouseDown: of a window close button is confusing the NSDocument.</p> <p>So now, I have to return, and pepper my apps main loop with unmaintainable state machine logic to prevent user from executing various dangerous hotkeys.</p> <p>Ok, so I grin and bear it, and run into yet another roadblock!</p> <p>In previous OS versions/SDKs, [NSApp modalWindow] would return a window when it was in this state. Now it doesn't! Grrrrr...<br> NSDocument has no API to test when it is in this state!</p> <p>So, now there is no mechanism to globally check this state! I have to add yet another state variable to my state machine.</p> <p>Anyone have a cleaner solution for this problem that works in all OS versions and all present (and future) SDKs?</p>
    singulars
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload