Re: Open document panel always on top - Mountain Lion
On 10/10/14, 8:29 PM, "Quincey Morris" mailto:quinceymor...@rivergatesoftware.com>> wrote: On Oct 10, 2014, at 13:34 , Matthew LeRoy mailto:mle...@minitab.com>> wrote: Not entirely sure where to go from here. It’s not clear to me whether the deferral of the open panel’s disappearance is a mere implementation detail of NSDocumentController, or if it’s a consequence of what you chose to do in your completion handler. I think I’d be inclined to sacrifice a bit of time to experiment with handling the open panel yourself, in advance of diving into NSDocumentController, at least for the handling of passwords. That is, provide your own action method in place of ‘openDocument:’ for the relevant menu item. Then you can ‘orderOut:’ the open panel exactly when you want, and any duplication of effort may be less (in terms of development time and pain) then “customizing” the behavior of NSDocumentController. Just wanted to follow up on this and relay my “solution” for posterity. Before starting this thread, I was already providing my own custom action method in place of ‘openDocument:' as you suggested, but for a different reason: I needed to customize the way that a certain type of document (call it Type A, different from the document type with the password, call it Type B) was opened. My custom action method just called [self beginOpenPanelWithCompletionHandler:], passing a custom completion handler. In the completion handler, I looped over the URLs and checked the document type for each one. If it was Type A I did my custom opening logic; for every other type I called [self openDocumentWithContentsOfURL:…]. After moving my password-checking logic out of -[NSDocument readFromURL:…] and into an override of -[NSDocumentController openDocumentWithContentsOfURL:…], I started having the problem of the Open panel staying up and obscuring the password dialog on both 10.8 and 10.9 — a regression, as I was only having the problem on 10.8 originally. Out of curiosity, I tried removing my custom action method and instead just using openDocument:, and lo and behold the problem went away on both 10.8 and 10.9. Only problem was that I lost my custom opening logic for Type A documents because it was implemented in the custom completion handler passed to ‘beginOpenPanelWithCompletionHandler:’, inside my custom action method. But then it occurred to me that a better place to implement the custom logic for Type A documents was inside the override of -[NSDocumentController openDocumentWithContentsOfURL:…], where I was now providing the password-checking logic for Type B. So, I re-implemented the Type A opening logic there, got rid of my custom action method and used openDocument: instead, and now everything is working. So the bottom line is that for whatever reason, calling -[NSDocument beginOpenPanelWithCompletionHandler:] and passing my own completion handler, rather than just using openDocument:, caused the Open panel to not order out early enough in the process. Many thanks for the suggestions and guidance as I worked through this! ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Open document panel always on top - Mountain Lion
On Oct 10, 2014, at 13:34 , Matthew LeRoy wrote: > Not entirely sure where to go from here. It’s not clear to me whether the deferral of the open panel’s disappearance is a mere implementation detail of NSDocumentController, or if it’s a consequence of what you chose to do in your completion handler. I think I’d be inclined to sacrifice a bit of time to experiment with handling the open panel yourself, in advance of diving into NSDocumentController, at least for the handling of passwords. That is, provide your own action method in place of ‘openDocument:’ for the relevant menu item. Then you can ‘orderOut:’ the open panel exactly when you want, and any duplication of effort may be less (in terms of development time and pain) then “customizing” the behavior of NSDocumentController. Also keep in mind the other possibility: have your ‘readFromURL:’ method defer the password checking and the reading of the document until the window is open (and do the password interaction as a sheet on that window). That might also be worth a bit of time to experiment, even if it turns out to be infeasible. ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: 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 (Cocoa-dev@lists.apple.com) 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Open document panel always on top - Mountain Lion
On Oct 9, 2014, at 13:44 , Matthew LeRoy wrote:
> so -[NSDocumentController beginOpenPanelWithCompletionHandler:] is what I
> would be using.
> Hmm, OK. So where do I provide the custom completion handler?
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:
- (void)openDocumentWithContentsOfURL:(NSURL *)url
display:(BOOL)displayDocument completionHandler:(void (^)(NSDocument*document,
BOOL documentWasAlreadyOpen, NSError *error))completionHandler {
if ([self typeForContentsOfURL: url …] != myOldType
[super openDocumentWithContentsOfURL: url display:
displayDocument completionHandler: completionHandler];
else
dispatch_async (dispatch_get_main_queue (), ^{
[SomeClass verifyPasswordForURL: url
completionHandler: ^(NSError* error) {
if (error == nil)
[super
openDocumentWithContentsOfURL: url display: displayDocument completionHandler:
completionHandler];
else if (completionHandler != nil)
completionHandler (nil, NO,
error);
}];
});
}
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.
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
Re: Open document panel always on top - Mountain Lion
On 10/9/14, 4:06 PM, "Quincey Morris"
mailto:quinceymor...@rivergatesoftware.com>>
wrote:
On Oct 9, 2014, at 12:33 , Matthew LeRoy
mailto:mle...@minitab.com>> wrote:
I agree this sounds like a better idea. There’s no good reason I can’t prompt
for and validate the password prior to actually opening and reading the
document contents, provided I have access to the document’s URL. However, I’m
not entirely sure how to go about it…
It depends on which API you’re using. It isn’t clear from your original post
whether you’re using different API for different deployment targets.
Ah yes, I should’ve specified that. We target 10.8 and newer and use the 10.8
SDK, so -[NSDocumentController beginOpenPanelWithCompletionHandler:] is what I
would be using.
It’s easier than that. In your completion handler, use 'dispatch_async
(dispatch_get_main_queue (), ^{…})’ to wrap the password and document code in
another block that’s queued on the main queue, and them simply return.
That unblocks the open panel (which has invoked your completion handler
synchronously), and allows it to dismiss the window. Your code will run
independently of that.
Hmm, OK. So where do I provide the custom completion handler? By overriding
openDocument: and calling beginOpenPanelWithCompletionHandler:, passing my
custom completion handler? Or do I override
beginOpenPanelWithCompletionHandler: and just call super, passing my own
completion handler which itself calls the default completion handler? In either
case it sounds like I’m going to have to re-implement in my completion handler
(or in the block that I queue on the main thread) some logic that I’m currently
getting for free, including looping through the URLs and opening each one,
presenting errors returned while opening any of the documents, etc.
This feels pretty early to be hooking into the whole process just to do
password checking for one document type. Could I override
openDocumentWithContentsOfURL:display:completionHandler: instead, do the
password checking first (if the document is the right type) and then just call
super?
Or, do I need to hook in earlier because the default implementation (at least
on Mountain Lion) doesn’t appear to close the open panel until after it has
opened all of the documents?
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
Re: Open document panel always on top - Mountain Lion
On Oct 9, 2014, at 12:33 , Matthew LeRoy wrote:
> I agree this sounds like a better idea. There’s no good reason I can’t prompt
> for and validate the password prior to actually opening and reading the
> document contents, provided I have access to the document’s URL. However, I’m
> not entirely sure how to go about it…
It depends on which API you’re using. It isn’t clear from your original post
whether you’re using different API for different deployment targets.
In an open panel completion handler, ‘openPanel.URLs’ is the array of URLs that
the user chose.
In the -[NSDocumentController beginOpenPanelWithCompletionHandler:] completion
handler, the array of URLs is passed as a parameter.
If you’re using older API, then -[NSDocumentController
URLsFromRunningOpenPanel] might be the way to get the array of URLs.
> The documentation for [NSDocumentController
> beginOpenPanelWithCompletionHandler:] states in the Discussion section that
> the default completion handler “determines which button the user pressed …
> and orders out the open panel”. Presumably I would want to wait until after
> the default completion handler runs and orders out the open panel before I do
> my password checking to avoid the open panel being in the way… but the
> default completion handler is what creates/opens the documents, so if I wait
> until after the completion handler runs then my readFromURL: will have
> already been called and the document will have been opened — too late to do
> password checking. Also, it appears that on Mountain Lion the documents are
> opened first and then the open panel is ordered out, while on Mavericks
> (where I do not have this problem) the open panel is ordered out prior to the
> documents being opened.
It’s easier than that. In your completion handler, use 'dispatch_async
(dispatch_get_main_queue (), ^{…})’ to wrap the password and document code in
another block that’s queued on the main queue, and them simply return.
That unblocks the open panel (which has invoked your completion handler
synchronously), and allows it to dismiss the window. Your code will run
independently of that.
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
Re: Open document panel always on top - Mountain Lion
On 10/9/14, 1:00 PM, "Quincey Morris" mailto:quinceymor...@rivergatesoftware.com>> wrote: On Oct 9, 2014, at 07:21 , Matthew LeRoy mailto:mle...@minitab.com>> wrote: My document-based application can potentially display an app-modal dialog via [NSApp runModalForWindow:] from within my override of [NSDocument readFromURL:ofType:error:] I dunno, but this seems like a really, really bad idea. Although ‘readFromURL’ looks like a fairly top-level method in your source-code, when it’s called you are (call-wise) deep in the bowels of NSDocument. Stalling the whole process while you ask the user a question may not be the best thing to do. I’ll freely admit that I never felt very comfortable with running a modal dialog from within readFromURL:, but it seemed to work (that is, until I ran into this issue) so I went with it. Without knowing the details of your use-case, I’d suggest that it’s preferable to ask for and validate the password before opening the document. You would trigger this from the NSOpenPanel completion handler, but if you use any blocking methods, don’t try to do it *in* the completion handler, otherwise the open panel may still be in your way. I agree this sounds like a better idea. There’s no good reason I can’t prompt for and validate the password prior to actually opening and reading the document contents, provided I have access to the document’s URL. However, I’m not entirely sure how to go about it… The documentation for [NSDocumentController beginOpenPanelWithCompletionHandler:] states in the Discussion section that the default completion handler “determines which button the user pressed … and orders out the open panel”. Presumably I would want to wait until after the default completion handler runs and orders out the open panel before I do my password checking to avoid the open panel being in the way… but the default completion handler is what creates/opens the documents, so if I wait until after the completion handler runs then my readFromURL: will have already been called and the document will have been opened — too late to do password checking. Also, it appears that on Mountain Lion the documents are opened first and then the open panel is ordered out, while on Mavericks (where I do not have this problem) the open panel is ordered out prior to the documents being opened. A couple of other issues about checking passwords in ‘readFromURL’ that you may or may not have yet considered: — If your app is starting up and being given an autosaved untitled document to open, it’s not clear what password behavior you want, or what behavior you’re going to get, if you have the password check in ‘readFromURL’. — If the user reverts the document, I think in the default case you’ll end up back at ‘readFromURL’, which presumably means you’ll ask for the password again. Again, it’s not clear if that’s what you really want. The only documents that I need to check passwords on are documents from an older document format that are always converted to an untitled (that is, unsaved) document in the new/current document format as part of the reading process (i.e. I call setFileURL:nil and setFileType:CurrentDocumentFileType at the end of readFromURL:), and the password is essentially removed from the (newly created) document at that point. So, there’s no way for an autosaved untitled document or a revert operation to end up trying to read a document in the old format and thus have to run through the password logic. ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Open document panel always on top - Mountain Lion
On Oct 9, 2014, at 07:21 , Matthew LeRoy wrote: > My document-based application can potentially display an app-modal dialog via > [NSApp runModalForWindow:] from within my override of [NSDocument > readFromURL:ofType:error:] I dunno, but this seems like a really, really bad idea. Although ‘readFromURL’ looks like a fairly top-level method in your source-code, when it’s called you are (call-wise) deep in the bowels of NSDocument. Stalling the whole process while you ask the user a question may not be the best thing to do. Without knowing the details of your use-case, I’d suggest that it’s preferable to ask for and validate the password before opening the document. You would trigger this from the NSOpenPanel completion handler, but if you use any blocking methods, don’t try to do it *in* the completion handler, otherwise the open panel may still be in your way. If there’s a good reason you can’t do it that early, I’d defer asking for the password until much later — in fact, make it a responsibility of the document’s window controller. Then, you can actually use a sheet of the (empty) document window, instead of a app-model panel, which I think is a better user experience anyway. Note you don’t have to try to read anything from the document until after you have the password — there’s nothing that requires ‘readFromURL’ to actually *do* anything. Document data may be loaded lazily, and waiting till after the password check is similar to laziness. I don’t recommend trying to intervene somewhere else in the middle of the document opening process (for example, putting up a modal dialog instead of creating the document window controller). I tried that sort of thing once and it just never worked right in all the paths through the document-opening mechanism. A couple of other issues about checking passwords in ‘readFromURL’ that you may or may not have yet considered: — If your app is starting up and being given an autosaved untitled document to open, it’s not clear what password behavior you want, or what behavior you’re going to get, if you have the password check in ‘readFromURL’. — If the user reverts the document, I think in the default case you’ll end up back at ‘readFromURL’, which presumably means you’ll ask for the password again. Again, it’s not clear if that’s what you really want. ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Open document panel always on top - Mountain Lion
You need to have the document content in order to test the password, right? This might be naive, but could you load the document into an offstage memory structure (meaning, don’t plug it into the user interface yet so the user cannot see or modify it) and ask for the password only after the load completes and the Open dialog goes away. If the user gets the password right, you plug the doc into the UI; otherwise you discard the offstage memory structure. -- Charles On Thursday, October 9, 2014 at 10:21, Matthew LeRoy wrote: > Good morning, > > My document-based application can potentially display an app-modal dialog via > [NSApp runModalForWindow:] from within my override of [NSDocument > readFromURL:ofType:error:], in order to prompt the user for the password to > open a document. For the most part, this works just fine. > > The trouble I’m running into is that on Mountain Lion my password dialog is > hidden behind the Open dialog, which remains open but non-responsive while my > document-reading code executes (i.e. It doesn’t response to mouse clicks, > can’t drag/move it out of the way to reveal the password dialog, etc). The > password dialog does become key, even though I can’t see it; I can press > ‘Esc’ to close it which cancels the opening process, or type the password > blindly and press ‘Enter’ and, assuming I got the password right, things will > proceed normally. If I switch to another application while the hidden > password dialog is waiting for user input, the still-open Open dialog from my > application remains on top, even on top of windows from other active > applications. The Open dialog is shown via the built-in document architecture > methods — I haven’t done anything to specialize it other than to modify the > enabled file types by overriding [NSDocumentController > beginOpenPanel:forTypes:completionHandler:] and [NSDocumentController > runModalOpenPanel:forTypes:]. > > On Mavericks, the Open dialog closes prior to my readFromURL: code executing, > and so the password dialog is visible and everything is fine. > > Any thoughts? I’ve tried calling [NSWindow setLevel:] with > NSModalPanelWindowLevel and NSStatusWindowLevel on the password dialog window > prior to calling [NSApp runModalForWindow:] with no luck. > > Thanks! > ___ > > Cocoa-dev mailing list (Cocoa-dev@lists.apple.com > (mailto:Cocoa-dev@lists.apple.com)) > > Please do not post admin requests or moderator comments to the list. > Contact the moderators at cocoa-dev-admins(at)lists.apple.com > (http://lists.apple.com) > > Help/Unsubscribe/Update your Subscription: > https://lists.apple.com/mailman/options/cocoa-dev/cejwork%40gmail.com > > This email sent to cejw...@gmail.com (mailto:cejw...@gmail.com) ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Open document panel always on top - Mountain Lion
Good morning, My document-based application can potentially display an app-modal dialog via [NSApp runModalForWindow:] from within my override of [NSDocument readFromURL:ofType:error:], in order to prompt the user for the password to open a document. For the most part, this works just fine. The trouble I’m running into is that on Mountain Lion my password dialog is hidden behind the Open dialog, which remains open but non-responsive while my document-reading code executes (i.e. It doesn’t response to mouse clicks, can’t drag/move it out of the way to reveal the password dialog, etc). The password dialog does become key, even though I can’t see it; I can press ‘Esc’ to close it which cancels the opening process, or type the password blindly and press ‘Enter’ and, assuming I got the password right, things will proceed normally. If I switch to another application while the hidden password dialog is waiting for user input, the still-open Open dialog from my application remains on top, even on top of windows from other active applications. The Open dialog is shown via the built-in document architecture methods — I haven’t done anything to specialize it other than to modify the enabled file types by overriding [NSDocumentController beginOpenPanel:forTypes:completionHandler:] and [NSDocumentController runModalOpenPanel:forTypes:]. On Mavericks, the Open dialog closes prior to my readFromURL: code executing, and so the password dialog is visible and everything is fine. Any thoughts? I’ve tried calling [NSWindow setLevel:] with NSModalPanelWindowLevel and NSStatusWindowLevel on the password dialog window prior to calling [NSApp runModalForWindow:] with no luck. Thanks! ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
