Apologies if this is a well-known and/or well-described topic, but I stumbled upon unexpected behavior of the choose folder scripting additions command, and a search of the MacScripter and other sites failed to return any discussion. The unexpected behavior is as follows:
When the choose folder command’s default location parameter value is set to a folder alias, the “choose” dialog window opens to the contents of that folder, as expected. However, when the default location parameter value is set to a file alias, not only does the “choose” dialog window open to the contents of that file’s containing folder, as expected, but it also (1) has its default selection set to the specified file, and (2) returns that file’s alias to the calling program if the user presses the OK button. Interestingly, if the user navigates away from the default selection, being a file and not a folder, it becomes unselectable thereafter.
The choose folder command’s purpose is clearly to provide a means for the user to get a reference (alias) to one or more folders interactively. The fact that, under the described circumstances, it can return a file reference instead seems at odds with the command’s basic purpose. I’m curious if there might be a rationale for this behavior that I am missing, or should this be considered a bug in the choose folder command?
I don’t know the answer, but I do know it happens for me in OS 10.13.4 and Script Debugger 7.0.2. The default choice is a file and it does return an alias but I can only move away from the default by choosing a folder instead and then it grays out the default or any other file and only allows folder choices.
Thank you for the feedback. I also discovered this behavior on OS 10.13.4. It would be interesting to confirm this behavior on older OS versions just to be sure it’s not something new that’s cropped up, as unlikely as that may be. Unfortunately, I don’t have access to older OS versions.
Fantastic that you are able to reach so far back. It is fascinating that this behavior cropped up somewhere in the middle history of AppleScript. I am inclined to report the current behavior as a bug to Apple and see what, if anything, comes of it.
What you’re seeing is not AppleScript specific. Here’s the same thing in AppleScriptObjC:
use AppleScript version "2.4"
use scripting additions
use framework "Foundation"
use framework "AppKit"
property chosenPath : missing value
on chooseFolder:thePath
set openPanel to current application's NSOpenPanel's openPanel()
tell openPanel
its setDirectoryURL:(current application's |NSURL|'s fileURLWithPath:thePath)
its setCanChooseDirectories:true
its setCanChooseFiles:false
end tell
-- show panel
set returnCode to openPanel's runModal()
if returnCode is (current application's NSFileHandlingPanelCancelButton) then
error number -128
end if
set my chosenPath to openPanel's |URL|()'s |path|() as text
end chooseFolder:
my performSelectorOnMainThread:"chooseFolder:" withObject:"/users/shane/Desktop/Dictionary.html" waitUntilDone:true -- change path to suit
return chosenPath
As you can see there’s no way Objective-C can even check if it’s a folder, because it’s possible to set whether files should be accepted later on. But the documentation – and the method name – make it clear that a directory is expected. So you’re in the realm of undocumented behavior – you didn’t pass what you were asked for, and there’s no guarantee what you will get.
The documentation for choose folder is also reasonably clear. You can argue that AppleScript should be more user friendly, and check that the file passed is actually a folder, or a package and that showing package contents is set to true, and that’s probably reasonable. But it’s arguable whether the current behavior is actually a bug – it may be unexpected, but all bets are off if you don’t pass what is asked for.
I understand the point you are making. And yet…I still find myself leaning bug-wards (or to express it with an Americanism, “If it looks like a bug, crawls like a bug, and buzzes like a bug, then it probably is a bug” :lol: ) for the following reasons:
(1) The choose folder command is capable of recognizing that the default location is set to a file and not a folder as soon as the user navigates away from default selection either by selecting a folder or making an up- or down-arrow key press to a folder in the dialog window, at which point the file immediately becomes unselectable. Why shouldn’t it be capable of making that very determination during processing of the input value?
(2) Thanks to Nigel Garvey’s historical insight, we know that that was in fact the choose folder command’s behavior in the good old days.
You’re mis-understanding what’s happening. When a dialog is set to show only folders, files get listed in a disabled state – they are greyed, and the user can’t click on them to select them. But that doesn’t mean they can’t be selected programmatically, which is what happens initially. If you look closely, you will see the initial selection is still in grey type, signifying that it cannot be selected by a user clicking on it. There’s no “becoming unselectable”.
A change in undocumented behavior is the very reason why relying on it is dangerous, but it’s not the definition of a bug.
The choose folder command’s dictionary lists the purpose of the command as:
Choose a folder on a disk or server
and the return value of the command as:
alias: the chosen folder
And here’s Wikipedia’s definition of a software bug:
A software bug is an error, flaw, failure or fault in a computer program or system that causes it to produce an incorrect or unexpected result, or to behave in unintended ways. (my underlines)
Not particularly. The clear implication is that you use it correctly, with the correct parameters. That’s the contract.
If you pass a file rather than a folder, it’s a bug in your code. It would be ideal if the command cleaned up for you, or perhaps threw an error, or ignored the parameter – but to suggest it has an obligation to is, I think, going too far. It doesn’t say it will, and it doesn’t.
It’s a testament to my G5, which I bought only a day or two before Apple announced it was switching to Intel processors :mad: and which has proved the most reliable and longest-lived of my computers so far — if not particularly useful in recent years.
It’s AppleScript Engineering you have to convince.
I understand much better the point you are making. I find these kinds of discussions to be a purifying fire that forces clarity of thought and expression. In the current case, it would be interesting to learn more about the topics of developer obligation, undocumented behavior, and bugs, but that’s getting too far off course.
That is where my thoughts were going. It seems that it must come down to the AppleScript engineers either wanting this behavior, in which case it would be nice if it were documented, or not wanting this behavior, in which case they should remove it. I’ll file a “bug” report (in quotes; it’s the only venue I’m aware of for submitting this!) but state the matter in these terms, then see what comes of it.
10.5.8 file type determination was done by Carbon’s (OSType) codes. Modern OS X systems favors the much more flawed UTI schemes. IIRC user interaction of the StandardAddition was all Carbon till at least Snow Leopard. That would explain the difference in behavior.
That was my suspicion, too. Which means it would have been using Navigation Services.
Satimage.osax still has Navigation Services dialog commands, including navchoose folder. Of course it won’t run in 64-bit mode. But if you run it from a 32-bit host, like this:
navchoose folder starting at alias "Macintosh HD:Users:shane:Desktop:Dictionary.html"
I submitted the matter to Apple’s Bug Reporter under the title Unexpected behavior of AppleScript’s “choose folder” command and referenced the fact that the expected behavior used to be present when file typing was done with Carbon’s OSType codes.
Let’s see if a small miracle comes of this.
Incidentally, I would find it useful if the choose folder command reverted to its prior behavior of permitting its default location parameter to be set to a file alias and then opening to the containing folder of that file without any items pre-selected. That would eliminate the unintended consequence of getting an alias to a file if the user presses the “Choose” button without selecting any other items. Currently, the programmer must perform the extra step of extracting the file’s containing folder first and then using the extracted folder alias as the value of the default location parameter in order to achieve this desirable behavior.
I wasn’t explaining or confirming a bug, just explaining difference in behavior between OS Base SDKs. Once you understand the difference Carbon and Cocoa, it becomes clear why it behaves differently.
choose folder command is not a special command in AppleScript, or a command specially written for AppleScript. In the early days NavChooseFolder() was called from the Carbon framework who had similar arguments as the choose folder in AppleScript. Choose folder command was nothing more than an translation between AppleScript and Carbon. A lot of these commands was nothing more than a 1:1 translation from the Carbon functions/methods. However in Cocoa these Nav… functions doesn’t exist; so they’re replicated as close as possible but can’t be an exact replica as choose folder has proven.
While difference in behavior I agree with Shane, this isn’t a bug. It’s an undocumented and unannounced transition from Carbon to Cocoa which make choose folder behave differently. It’s not a bug because every part is intentional and nothing is unexpected (from AppleScript Engineers point of view).
However the choose folder command is implemented since the transition to Cocoa, the current behavior still seems odd. The command simply should not allow a non-folder to be set as the default selection, nor should it return a reference to a non-folder to the calling program.
Rather than confine themselves to a 1:1 translation of whatever Cocoa technology they are currently using behind the scenes, wouldn’t it be an almost trivial task for the AppleScript engineers to modify the implementation such that the command allows only folders to be pre-selected and only folders to be returned to the calling program? Choosing and returning folders is, after all, the very reason for the command’s existence.
P.S. I should have begun by saying that I completely understand the point you and Shane have been making, that the current behavior of the command is its expected behavior. The report I submitted simply makes the request that they consider modifying the implementation so that its behavior reverts to that of the old choose folder command, which I find not only more intuitive but also more useful for the reason I described in the last paragraph of my previous post.
Don’t forget the showing package contents parameter which makes packages behave like normal folders and allows you to choose packages as normal folders.
