On 02/07/2013, at 4:54 AM, Matthew LeRoy <mle...@minitab.com> wrote:
> Hi, > > I'm looking for some help troubleshooting some behavior with NSOpenPanel, > where it doesn't seem to be properly validating and updating the user > interface with respect to changes I'm making to allowedFileTypes. This is in > a Document-based app using the 10.7 SDK, running on 10.8.3. My first question would be: is your app sandboxed or not? If so, you are dealing with a very different implementation of NSOpenPanel than an un-sandboxed app, and one that has a history of being very buggy, so it's very likely that if you're sandboxed, that's about as far as you can go - it's buggy and you'll have to beg Apple to fix it for you. > I've subclassed NSDocumentController as suggested in the documentation so > that I can customize the open panel with my own accessory view. My accessory > view contains an NSPopUpButton listing the various file types my app can > open, and when a new file type is selected with the popup button my > controller calls -setAllowedFileTypes: followed by -validateVisibleColumns on > the NSOpenPanel, as suggested by the documentation. > > This works, but only partially. When the file type selection is changed, I am > no longer able to select files of the previous type, and I am only able to > select files of the new type -- so far, so good. However, the visual > appearance of the files listed in the open panel does not change; that is, > the files that are no longer valid (because they don't match the selected > type) are not grayed-out/dimmed, and those that are valid remain > grayed-out/dimmed. Note that I can still select the valid files even though > they look disabled (grayed-out), and I cannot select the invalid files even > though they look enabled (full black text). This happens in 3 of the 4 file > view modes (Icon, List, and Cover Flow); in Browser view mode, the visual > appearance updates as expected to match which files are actually valid and > selectable. I have tried additionally implementing -[NSOpenSavePanelDelegate > panel:shouldEnableURL:], but the behavior is the same. In the sandboxed case, the delegate is not allowed to do anything with the file referenced by the URL, so if your delegate method is attempting to access the URL to determine whether to enable the item or not, it might be throwing an exception which is interrupting the refresh. Looking at the extension of the path should be OK, but that's about it. > An additional bit of odd behavior is that in Icon, List, and Cover Flow view > modes, if I select a valid file and then change the enabled file type, the > selected file is deselected leaving no selection (and thus the Open button is > disabled). However, in Browser mode the selected file is not deselected when > the file type is changed and the Open button remains enabled, even though the > file is no longer valid. I can click Open and my app will proceed with > opening the selected file, even though it shouldn't be allowed because it > doesn't match the allowedFileTypes. This seems like a bug. > > Any thoughts or insight on either of these two issues? It sounds like it's working except for a refresh to the view displaying the files. It might be possible (assuming the unsandboxed case) to find subviews of the panel and force them to refresh, or force a refresh on the window as a whole. It's not clear why this should be necessary other than it being a bug, unless it's not getting as far as refreshing due to an internal exception. --Graham _______________________________________________ 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
