Thank you for pointing that out. I hadn’t looked at the role of the showing package contents parameter in all of this. But its behavior highlights even more, at least from my perspective, the nonintuitive nature of the choose folder command’s current behavior.
With the showing package contents parameter set to true and the default location parameter set to a package (in this case, the TextEdit.app bundle), the choose folder window opens to the contents of the package, as expected:
set texteditBundleAlias to ((path to applications folder as text) & "TextEdit.app") as alias
choose folder default location texteditBundleAlias with showing package contents
--> Opens to the contents of the TextEdit.app package, as expected
However, with the showing package contents parameter set to false and the default location parameter set to the TextEdit.app bundle, the choose folder window still opens to the contents of the TextEdit.app bundle, rather odd behavior given that the expression without showing package contents appears explicitly in the command (and again reflecting the seeming absence of filtering of the default location parameter value in the current implementation of the command):
set texteditBundleAlias to ((path to applications folder as text) & "TextEdit.app") as alias
choose folder default location texteditBundleAlias without showing package contents
--> Opens to the contents of the TextEdit.app package, even though the command reads: "without showing package contents"
I wonder if I might impose on Nigel to travel back in his time machine and see how the command behaved back in the NavChooseFolder days with the showing package contents parameter set to false. I suspect (and would hope) that the window would treat the TextEdit.app bundle as a non-folder and instead open to the contents of its containing folder, namely the Applications folder.
You’re missing DJ’s point: the behavior is set by the underlying Cocoa framework. The choose folder command is just AppleScript giving access to the NSOpenPanel class.
If you want to log a bug/request on the behavior with bundles, then at least log it where it belongs: the NSOpenPanel class.
It’s hard enough to get even serious AppleScript bugs fixed these days, and asking for precious time to be spent on trivia risks being counter-productive, IMO.
That’s exactly what I meant. The behavior has always been set by the underlying framework/API and was never defined by AppleScript itself. Supporting the behavior of an API that’s been deprecated since the 32-bit to 64-bit transition of Mac OS X and denying the behavior of currently supported API is what I would call nonintuitive.
Somewhere in the future the Carbon API will no longer ship with Mac OS X (by default). When that day happens and bmose request would be granted, choose folder’s behavior follows an phantom.
I would suggest the same thing. AppleScript doesn’t define the behavior of choose folder and bmose doesn’t like how NSOpenPanel works compared to NavChooseFolder. Why should this problem be addressed at OSAX-level while knowing that every application who let the end user choose an folder using NSOpenPanel have the same potential “bug”?
@bmose: The reason why I’m so stubborn on this subject is only because I prefer an OS where open and save windows behave exactly the same in all applications with no exceptions. I don’t see any reason why AppleScriptObjC’s NSOpenPanel should behave differently from choose folder while both solutions eventually uses the same NSOpenPanel.
Shane and DJ, forget it, it’s too late to apologize! (Sorry, just kidding. I couldn’t resist an old Bennie Hill joke. Bennie said that after he had bungled something up badly but, because of a language barrier, was clueless as to his own culpability. )
I’ll just go back to grinding it out: #1 extract a file’s containing folder with System Events, Finder, Cocoa, or the shell → #2 execute the choose folder command with the default location parameter set to that value → repeat at #1 → …
An alternative, I suppose, would be to write one’s own “choose folder” or NSOpenPanel wrapper that restores the old behavior.
I received the following reply from the Apple Bug Reporter:
I don’t have macOS 10.14 beta installed and was wondering if someone who does have it installed might be able to test this out.
To test the matter, one would issue a choose folder command with the default location set to the alias of an existing file, not a folder. If the issue has indeed been resolved, the “choose” dialog window should open to the file’s containing folder without the file highlighted as the default selection. The following command would work:
choose folder default location alias ((path to library folder from user domain as text) & "Safari:Bookmarks.plist")
The “choose” dialog window should open to the user library’s Safari folder, and the Bookmarks.plist file should not be selected if the issue is resolved.
Just to close the loop now that macOS 10.14 is out, Apple did indeed restore the choose folder command’s former behavior. It now opens to the default location’s containing folder without pre-selecting the file when the default location is set to the alias of a file. To demonstrate, save a file (not a folder) on the desktop, for example, an AppleScript script named SampleScript.scpt. Then run the following command:
choose folder default location (((path to desktop as text) & "SampleScript.scpt") as alias)
The choose folder dialog window will open to the desktop folder withoutSampleScript.scpt being pre-selected.
I was hoping the fix would have been implemented at the level of Cocoa’s NSOpenPanel. I tested NSOpenPanel’s behavior using the script Shane Stanley posted earlier in this thread. Unfortunately, the dialog window still opens with the file pre-selected even though NSOpenPanel’s setCanChooseFiles: method is set to false.
)