Re: Open document panel always on top - Mountain Lion
Re: Open document panel always on top - Mountain Lion
- Subject: Re: Open document panel always on top - Mountain Lion
- From: Matthew LeRoy <email@hidden>
- Date: Fri, 10 Oct 2014 20:34:14 +0000
- Thread-topic: Open document panel always on top - Mountain Lion
Ah, I see, I thought you were already *providing* a completion handler somewhere, but I guess you’re not. In that case, I think you would override -[NSDocumentController openDocumentWithContentsOfURL:display:completionHandler:], like this:
… snip …
Just make sure that the password verification (which is invoked on the main thread) doesn’t eventually invoke its completion handler on a background thread — or if it must, then wrap the innermost if/else in another dispatch_async (dispatch_get_main_queue (), …) block.
With this code (warning: written in Mail) you’re getting all the normal document behavior, and reporting a password verification failure through the normal document mechanism.
Not quite there yet… but getting closer (I think)!
I overrode -[NSDocumentController openDocumentWithContentsOfURL:display:completionHandler:] as you suggested — the code is extremely similar to the snippet you sent — and it actually made things worse: the Open panel obscures the password dialog on Mavericks now, too, as well as Mountain Lion. However, I’m inclined to stick with this approach (as opposed to doing the password prompting and checking in readFromURL:…) since it seems more appropriate.
I was thinking again about the tidbit in the docs for -[NSDocumentController beginOpenPanelWithCompletionHandler:] that I mentioned previously, about how the completion handler “orders out the open panel”. Looking back through the rest of my code I was reminded that I am not calling [NSDocument openDocument:] in this scenario, but rather my own IBAction which is called from a separate menu item for opening older-format documents, where I simply call [NSDocument beginOpenPanelWithCompletionHandler:] and pass my own completion handler, which then loops through the URLs chosen by the user and opens each one by calling openDocumentWithContentsOfURL:display:completionHandler:. There’s a bit more logic in there that makes it behave differently than openDocument: that I’m fairly certain isn’t relevant in this case, but that’s the gist of it. (And don’t ask me why there are separate menu items for opening current-format documents and older-format documents — not my decision, and not one that I have the ability to change, much as I’d like to).
Anyway, it occurred to me that since the completion handler getting passed to beginOpenPanelWithCompletionHandler: is my own and not the standard completion handler that would be passed by openDocument:, that might be why the Open panel isn’t getting dismissed earlier. Sure enough: if I instead just call openDocument: rather than beginOpenPanelWithCompletionHandler: with my custom completion handler, then the Open panel closes before the password prompt on both Mavericks and Mountain Lion and everything (related to the password prompt) is peachy. This is with the modifications to the password-checking logic that you suggested — dispatch_async(…) to the main queue in -[NSDocumentController openDocumentWithContentsOfURL:…] rather than during -[NSDocument readFromURL:…]. Of course, it breaks other app functionality related to the logic that was in my custom completion handler passed to beginOpenPanelWithCompletionHandler:, but perhaps it sheds some light on the situation?
Not entirely sure where to go from here. I really appreciate your help so far in trying to sort this out.
_______________________________________________
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