On 10/9/14, 1:00 PM, "Quincey Morris" <quinceymor...@rivergatesoftware.com<mailto:quinceymor...@rivergatesoftware.com>> wrote:
On Oct 9, 2014, at 07:21 , Matthew LeRoy <mle...@minitab.com<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
