SINGLE step to choose ANY object (file or folder)

[Hal Itosis]

I see that AppleScript provides separate "choose file" and "choose folder" dialogs. But is there no single option (or some trick) which allows the user to select either a file or a folder (or multi-select several of both persuasions)?

I.e., i'd rather not have to toss up a second (intermediary) dialog à la:

...

set choice to display dialog ("Shall we select a file or folder?") ¬
buttons {"Cancel", "File", "Folder"} with icon note ¬
cancel button 1 default button 3
if button returned of choice is "File" then
choose file with prompt ¬
("Select a FILE (or several files):") ¬
with invisibles and multiple selections allowed
else
choose folder with prompt ¬
("Select a FOLDER (or several folders):") ¬
with invisibles and multiple selections allowed
end if

...because what happens next doesn't care which "kind" the choice was.

Is there no "choose whatever" dialog (or a shorter way to synthesize one)?

[renaultssoftware]

I know how you feel. I guess it's that way on purpose.

Please, Apple, understand this!

[tlarkin]

This sort of thing is why I rarely use Apple script for things at work. I almost exclusively use BASH, sometimes rarely perl or python, and is also the reason I am teaching myself python and ruby.

[regulus6633]

I see some applescript bashing going on. Maybe you didn't know but applescript is very powerful and can do virtually anything. Did you know that you can access objective-c methods from applescript? Did you know you can build custom windows in Interface Builder and run them from applescript? Well you can. See here (http://macscripter.net/viewtopic.php?pid=135210#p135210) for how to access these advanced capabilities...

As an example, I'll show you how to access objective-c methods so that you can have a dialog box which allows you to choose either a file or folder, or a combination of them. Try this.

Note 1: I only tested this on 10.6... not sure if it works on 10.5.
Note 2: you get back a list of posix paths, so you'll have to convert them into applescript-style paths if you want to use them further.

tell application "Automator Runner"
activate
set openPanel to call method "openPanel" of class "NSOpenPanel"
set trueBool to true
call method "setFloatingPanel:" of openPanel with parameter trueBool
call method "setCanChooseFiles:" of openPanel with parameter trueBool
call method "setCanChooseDirectories:" of openPanel with parameter trueBool
call method "setResolvesAliases:" of openPanel with parameter trueBool
call method "setAllowsMultipleSelection:" of openPanel with parameter trueBool
set theResult to call method "runModal" of openPanel
if theResult is 1 then -- 0 is returned when the cancel button is pressed
set chosenPaths to call method "filenames" of openPanel
end if
end tell

[renaultssoftware]

I never knew about being able to call Obj-C from 'vanilla' AppleScript. Thanks, regulus6633!

[Hal Itosis]

Did you know that you can access objective-c methods from applescript? Did you know you can build custom windows in Interface Builder and run them from applescript? Well you can. See here (http://macscripter.net/viewtopic.php?pid=135210#p135210) for how to access these advanced capabilities...

As an example, I'll show you how to access objective-c methods so that you can have a dialog box which allows you to choose either a file or folder, or a combination of them. Try this.

Note 1: I only tested this on 10.6... not sure if it works on 10.5.
Note 2: you get back a list of posix paths, so you'll have to convert them into applescript-style paths if you want to use them further.

tell application "Automator Runner"
activate
set openPanel to call method "openPanel" of class "NSOpenPanel"
set trueBool to true
call method "setFloatingPanel:" of openPanel with parameter trueBool
call method "setCanChooseFiles:" of openPanel with parameter trueBool
call method "setCanChooseDirectories:" of openPanel with parameter trueBool
call method "setResolvesAliases:" of openPanel with parameter trueBool
call method "setAllowsMultipleSelection:" of openPanel with parameter trueBool
set theResult to call method "runModal" of openPanel
if theResult is 1 then -- 0 is returned when the cancel button is pressed
set chosenPaths to call method "filenames" of openPanel
end if
end tell
Impressive (albeit somewhat complex).
Worked on the first try (10.6 here too).

Thanks. [though, i'll probably stick with the awkward 2-tiered approach until that (NeXTStep?) stuff feels more comfortable to me. E.g., how would we add a prompt string?]

[Hal Itosis]

This sort of thing is why I rarely use Apple script for things at work. I almost exclusively use BASH, sometimes rarely perl or python, and is also the reason I am teaching myself python and ruby.

i'd like to see a shell script that enables the operator to choose several sundry items simultaneously from a location on disk that is unknown until run time. [i.e., without resorting to osascript -e 'choose folder' (or file).]

It couldn't be that pretty. ;)

[regulus6633]

It does take some learning of objective-c and how to use "call methods" to access the objective-c. But there's a learning curve for anything. But this "open panel" is easy. We just get an open panel in the first line, then configure it any way we want in the following lines, then use "runModal" to display it. You can see all of the configuration possibilities by looking at NSOpenPanel's documentation here (http://developer.apple.com/library/mac/#documentation/Cocoa/Reference/ApplicationKit/Classes/NSOpenPanel_Class/Reference/Reference.html).

The beauty of objective-c is inheritance. You see in that link a section called "Inherits from". So you can look at those classes too, and since NSOpenPanel inherits from them then NSOpenPanel will respond to any of those methods too.

So in answer to your question use the "setMessage:" method of NSSavePanel. Add this anywhere in the code above the "runModal" line...
set theMessage to "Display some message text!"
call method "setMessage:" of openPanel with parameter theMessage

[Hal Itosis]

Cheers, thanks again!

[regulus6633]

Basically, Apple added the capability to access obj-c in Automator. So we can access automator capabilities from applescript using "Automator Runner"!

[tw]

I think the reason this is this way is that Apple figured there would be no real value in choosing both containers and items - whatever effort you save in being able to choose both you lose in having to distinguish between them for processing. if it helps any, there are two ways of doing what you want:
use the satimage osax, which has a 'choose item' command.
put your applescript in automator, and use automator's Ask for Finder Items action, which has a 'files and folders' option.

[Hal Itosis]

I think the reason this is this way is that Apple figured there would be no real value in choosing both containers and items - whatever effort you save in being able to choose both you lose in having to distinguish between them for processing.
In this case the selected items will simply be deleted in place, so there's nothing for AppleScript to distinguish. I.e., do shell script "rm -rf " gladly accepts both files and folders. [moving stuff to the trash and then emptying same is intentionally being avoided here, as deleting "in place" is the primary objective (and trash may currently contain items for which the user hasn't given final approval for removal... or, perhaps that user didn't put them there initially {maybe a USB stick belonging to a friend is mounted with trashed items or something... who knows}).]


if it helps any, there are two ways of doing what you want:
use the satimage osax, which has a 'choose item' command.
put your applescript in automator, and use automator's Ask for Finder Items action, which has a 'files and folders' option.
The osax is out, as i'm usually looking to just post some code in a forum that can be copy/pasted and run 'as is' on vanilla Mac OS. Automater sounds fine, but i've only ever spent 20 seconds looking at it (so it's still somewhat unfamiliar).

Interesting though... it seems one option is: "put the applescript in automator" (as you suggested), while another option appears to be the inverse of that: "put automator in the applescript" (as illustrated by regulus6633).

Still unsure to what degree Leopard/Tiger would present compatibility issues with those two options. Might just be less painful to go with the 2-stage method after all.

[tlarkin]

i'd like to see a shell script that enables the operator to choose several sundry items simultaneously from a location on disk that is unknown until run time. [i.e., without resorting to osascript -e 'choose folder' (or file).]

It couldn't be that pretty. ;)

I agree that BASH has it's limits, and I am not trying to dog on Apple Script because for what it does I don't know any other OS that provides anything similar to Apple Script itself.

I am not a developer, and I have never had any formal training so I could be speaking out of place here when I say this, but the reason I am starting to learn Python is that you can access Objective C APIs for some really cool and robust stuff. Plus Python is pretty easy to pick up from what I have already learned. Been watching the Google code classes on Python they posted online. There are Cocoa APIs you can access from python as well. There is also a ton of pre-built code out there you can import in your python coding.

Previously for user interaction I was using iHook, but to be honest all of the scripting/coding I do is for automation, silent installs, and so forth and do not really require all that much user interaction. In fact I prefer to not use user interaction unless it involves something like a reboot, and even then I usually just do a dialog box informing them they must reboot at their next convenience.

I did not know (but it doesn't surprise me) that Apple Script could access APIs of other languages, but then again I am not a developer. Thanks, Regulus6633 for correcting me. Did a bit of Google searching and found the dev page on Apple Script bridging.

http://developer.apple.com/library/mac/#documentation/applescript/conceptual/AppleScriptX/Concepts/scripting_bridge.html#//apple_ref/doc/uid/TP40006467-SW1

[tw]

well, if I were going to do what you're doing (a simple delete script), I'd make it a droplet/service and forget about dialog interactions. The open dialog is geared towards the idea that you're actually going to open the files and do something with them - if you're just trying to trash them it's as easy to select them in the finder and work from there.

I wrote a secure delete script a couple of years back and posted it at MacScripter - it's called Secure Delete.app. You might take a look at it for ideas. Unfortunately ScriptBuilders is down at the moment so I can't provide a link. I can post it if you like.

[Hal Itosis]

well, if I were going to do what you're doing (a simple delete script), I'd make it a droplet/service and forget about dialog interactions. The open dialog is geared towards the idea that you're actually going to open the files and do something with them - if you're just trying to trash them it's as easy to select them in the finder and work from there.
Already completed the droplet part. But what does your droplet do if someone double-clicks it... or runs it some other way with nothing selected in Finder? I would have mine at least offer the possibility of choosing items to delete at that point... not merely tell the user to go select some items in Finder and relaunch.

[tw]

Already completed the droplet part. But what does your droplet do if someone double-clicks it... or runs it some other way with nothing selected in Finder? I would have mine at least offer the possibility of choosing items to delete at that point... not merely tell the user to go select some items in Finder and relaunch.

My droplet is set up to be a Finder window menu bar item - if you launch it, it takes the items selected in the frontmost window, and if there are none it exits silently. If I were to implement a dialog, I'd probably use 'choose files' on the assumption that it's better to allow the files to be deleted and leave empty folders behind. If I wanted to be really sophisticated, I'd keep a short list of the container folders of the files that get deleted, and as a last step run through that list and delete empty containers.

[Hal Itosis]

Searching MacScripter for Secure Delete currently produces one hit (a post by "capitalj"):
http://www.google.com/search?q=site:macscripter.net+%22secure+delete%22

[tw]

Searching MacScripter for Secure Delete currently produces one hit (a post by "capitalj"):
http://www.google.com/search?q=site:macscripter.net+%22secure+delete%22

The script is actually (ostensibly, anyway) located here (http://scriptbuilders.net/files/securedelete1.0.html) - I posted it to the forums once before. however (as I said) the scriptbuilders section of MacScripter is temporarily down, so there's no access to it.

[Hal Itosis]

My droplet is set up to be a Finder window menu bar item - if you launch it, it takes the items selected in the frontmost window, and if there are none it exits silently.
Should do more than that... at least present a dialog explaining why nothing happens, or maybe a makeshift "about box" that gives up after 3 seconds.


If I were to implement a dialog, I'd probably use 'choose files' on the assumption that it's better to allow the files to be deleted and leave empty folders behind. If I wanted to be really sophisticated, I'd keep a short list of the container folders of the files that get deleted, and as a last step run through that list and delete empty containers.
That's assuming too much and not offering enough. User might want to shred an entire folder by simply selecting the folder (not by having to select all 123 items inside), and/or they might want to shred the 2 items in ~/Downloads without having the folder itself mysteriously disappear afterwards.

[tw]

Should do more than that... at least present a dialog explaining why nothing happens, or maybe a makeshift "about box" that gives up after 3 seconds.

true enough - maybe I'll write a revision to mine.

That's assuming too much and not offering enough. User might want to shred an entire folder by simply selecting the folder (not by having to select all 123 items inside), and/or they might want to shred the 2 items in ~/Downloads without having the folder itself mysteriously disappear afterwards.

well, if they want to shred all of the items in a folder all they need to do is open the folder and type ctrl-A. And if you want more control than that you're probably going to have to give up on the idea that this should be a simple script - either go with the 'call method' routine described above or make it a package and include the satimage osax or a custom nib. Either way you're stepping out of 'vanilla applescript' range.

[Hal Itosis]

tell application "Automator Runner"
activate
set openPanel to call method "openPanel" of class "NSOpenPanel"
:
:
:
set theResult to call method "runModal" of openPanel
I'm stumped. :confused:
When i google for phrases like "call method openPanel" and "call method runModal" ...this thread here is the only result.
How can that be? From where are you getting this info?



set trueBool to true
call method "setFloatingPanel:" of openPanel with parameter trueBool
call method "setCanChooseFiles:" of openPanel with parameter trueBool
call method "setCanChooseDirectories:" of openPanel with parameter trueBool

Seems unusual doing things that way. (unless we might want to toggle trueBool to false)
Is there an alternate syntax that looks less contrived.


Also (speaking of syntax) —if i open the sdef dictionary of Automator Runner.app with AppleScript Editor —the only mention of "openPanel" looks more like this...open-panel n [inh. save-panel > panel > window > item] : The open panel
PROPERTIES
allows multiple selection (boolean) : Can multiple items be selected?
can choose directories (boolean) : Can directories be selected?
can choose files (boolean) : Can files be selected?
path names (list, r/o) : list of path names chosen

...all of which is different from the syntax in your example (e.g., "filenames" versus "path names").

I'm confused. (given the google situation mentioned earlier): How/where can i see those "call methods" you came up with? Where is this stuff documented??? have found a bunch of cocoadev/openstep/gnustep pages... but none of them make the connection back to obtaining the proper calls from AppleScript.]

[edit]

Hmm okay, you'll probably refer me to the NSOpenPanel Class Reference (http://developer.apple.com/library/mac/#documentation/Cocoa/Reference/ApplicationKit/Classes/NSOpenPanel_Class/Reference/Reference.html) page again. I guess the lack of examples there is what's throwing me. Everywhere that "runModal" is described, it never gets used in an AppleScript context. [the word AppleScript isn't even mentioned once, nor is "call method".]

Bizarre.

[renaultssoftware]

Indeed, the NSOpenPanel is what you are looking for.

[tw]

I guess the lack of examples there is what's throwing me. Everywhere that "runModal" is described, it never gets used in an AppleScript context. [the word AppleScript isn't even mentioned once, nor is "call method".]

call method appeared about the same time as AppleScript Studio, and as far as I can tell suffered the same fate. it was originally (I think) supposed to be called from an XCode context (allowing one to access cocoa objects that didn't have predefined ASS hooks), but they built it into Automator Runner and Applescript Runner as well (mostly, I think, as a bridge between ASS projects and normal applescripting). for some reason it doesn't work the same in the two runners, incidentally - the given script works in automator runner but not applescript runner.

I see it as more of an occasionally useful trick than anything else - at any rate, I rarely run into situations where I even consider using it.

[Hal Itosis]

Indeed, the NSOpenPanel is what you are looking for.
Hardly. As indicated: not a scrap of "call method" documentation (for AppleScript) exists there whatsoever. [and why is this thread the only place in the world with the string "call method runModal"?]

Try again.

--

[the "legacy" pdf AppleScript Studio Terminology Reference (31-Oct-2007) and the Automator Programming Guide (on Interapplication Communication) pdf may have what i'm looking for.]


call method appeared about the same time as AppleScript Studio, and as far as I can tell suffered the same fate. it was originally (I think) supposed to be called from an XCode context (allowing one to access cocoa objects that didn't have predefined ASS hooks), but they built it into Automator Runner and Applescript Runner as well (mostly, I think, as a bridge between ASS projects and normal applescripting). for some reason it doesn't work the same in the two runners, incidentally - the given script works in automator runner but not applescript runner.
Much thanks tw.

[renaultssoftware]

Here's the Automator Runner.sdef entry for call method:
call method v : calls the given method of the object with the specified parameters
call method specifier : the object for the command
[of any] : the object to send the method to (exclusive from the "of class" parameter)
[of class text] : the class to send the method to (exclusive from the "of object" parameter)
[of object any] : deprecated in favor of the "of" parameter
[with parameter any] : a parameter to be passed to the method (exclusive of "with parameters")
[with parameters list] : a list of parameters to be passed to the method (exclusive of "with parameter")
It's up to you to use this properly.

The following sequence of code (for demo purposes):
NSWorkspace * workspace = [NSWorkspace sharedWorkspace];
NSURL * webSite = [NSURL URLWithString:@"http://www.apple.com/"];
[ws openURL:webSite];

is representable as this:

tell app "Automator Runner"
set workspace to call method "sharedWorkspace" of class "NSWorkspace"
set webSite to call method "URLWithString:" of class "NSURL" with parameter "http://www.apple.com"
call method "openURL:" of workspace with parameter webSite
end tell

[Hal Itosis]

set trueBool to true
call method "setFloatingPanel:" of openPanel with parameter trueBool
call method "setCanChooseFiles:" of openPanel with parameter trueBool
call method "setCanChooseDirectories:" of openPanel with parameter trueBool
call method "setAllowsMultipleSelection:" of openPanel with parameter trueBool


Seems unusual doing things that way. (unless we might want to toggle trueBool to false)
Is there an alternate syntax that looks less contrived?
Found that much. Seems those 5 lines can be rephrased as these 4:
call method "setFloatingPanel:" of openPanel with parameters {true}
call method "setCanChooseFiles:" of openPanel with parameters {true}
call method "setCanChooseDirectories:" of openPanel with parameters {true}
call method "setAllowsMultipleSelection:" of openPanel with parameters {true}

I.e., pluralize the "parameter" keyword, and put "true" into a {single-item} list.
Still a bit odd, but feels less awkward.

--

EDIT: observe that, if we attempt to use:
with parameter true
the compiler rewords it as:
with with parameter
which looks rather silly to me. [then again, requiring that boolean in the first place also seems somewhat ridiculous]

[tw]

EDIT: observe that, if we attempt to use:
with parameter true
the compiler rewords it as:
with with parameter
which looks rather silly to me. [then again, requiring that boolean in the first place also seems somewhat ridiculous]

That's an AppleScript thing. you should use either with parameter or parameter true, because applescript will explicitly translate the latter into the former. Frankly, it's one of the least intuitive/english-like conventions that AppleScript uses, but...

[Hal Itosis]

That's an AppleScript thing. you should use either with parameter or parameter true

Neither of these two versions will even compile...
call method "setFloatingPanel:" of openPanel with parameter
call method "setFloatingPanel:" of openPanel parameter true
...so perhaps i misunderstand what you meant there.

Here's what the AppleScript Studio Terminology Reference (Legacy) says:


You must use the with parameters parameter to pass a boolean value, even though it is a single parameter. You pass the boolean value as a single-item list. For example, to set the scrollable property of a matrix, you could use this statement:
call method "setScrollable:" of matrix 1 of window 1 with parameters {true}

[tw]

Neither of these two versions will even compile...
call method "setFloatingPanel:" of openPanel with parameter
call method "setFloatingPanel:" of openPanel parameter true
...so perhaps i misunderstand what you meant there.

Here's what the AppleScript Studio Terminology Reference (Legacy) says:

well, then ASS is violating ApplesScript's normal conventions. Not the first time Apple has done that (note the clipboard commands in Standard Additions osax)

[renaultssoftware]

(note the clipboard commands in Standard Additions osax)

Those bug me crazy. The 'clipboard' is not the same as 'the clipboard' for some reason :confused:

[Red_Menace]

The "call method" stuff appears to be a last minute hack to let you call methods that haven't been included in AS Studio's terminology yet. This is probably one of the reasons why it was deprecated in favor of a framework that just lets you call everything more-or-less natively. AppleScriptObjC also has a few odd things due to some coercions across the scripting bridge, so you see some of those kinds of weird parameters there also.

There are already other AS Studio commands for open panels (see the legacy AS Studio Reference) instead of all those call methods, for example:

tell application "Automator Runner" to tell open panel
get it's properties -- a little easier to use these rather than a bunch of 'call method'

set floating to true
set can choose directories to true
set allows multiple selection to true

activate
if (display it) is 0 then -- cancel button
return missing value
else
return it's path names
end if
end tell

[Hal Itosis]

There are already other AS Studio commands for open panels (see the legacy AS Studio Reference) instead of all those call methods, for example:

tell application "Automator Runner" to tell open panel
get it's properties -- a little easier to use these rather than a bunch of 'call method'
Looks promising... i'll check it out.

Thanks.

[Hal Itosis]

The "call method" stuff appears to be a last minute hack to let you call methods that haven't been included in AS Studio's terminology yet. This is probably one of the reasons why it was deprecated in favor of a framework that just lets you call everything more-or-less natively.

Thanks again for that simpler syntax... it was exactly what i'd hoped for. Only one minor feature missing...

In ordinary AppleScript, both choose file and choose folder offer a "with invisibles" option, which shows files like .DS_Store and folders like .Trash, etc. But AFAICT, open panel does not officially furnish that particular ability :confused: (despite providing the somewhat more obscure "treat packages as directories" property).

Might that "with invisibles" item exist in open panel perhaps (or one of its progenitors), and merely be hidden... yet still available via the convoluted call method route? Or some other way maybe?

[Red_Menace]

The open panel inherits from the save panel, and the NSSavePanel class has a setShowsHiddenFiles: method. A quick test seems to indicate that setting the level property (???) of the open panel to 3 will show invisibles, but you can just add a call method (for example, in my previous snippet, the following would be added in the tell statement when setting the other parameters):
call method "setShowsHiddenFiles:" of it with parameters {true}

[Hal Itosis]

The open panel inherits from the save panel, and the NSSavePanel class has a setShowsHiddenFiles: method. A quick test seems to indicate that setting the level property (???) of the open panel to 3 will show invisibles, but you can just add a call method (for example, in my previous snippet, the following would be added in the tell statement when setting the other parameters):
call method "setShowsHiddenFiles:" of it with parameters {true}
You sir are "mad, bad, and dangerous to know."

A thousand thanks.
[thread solved]

[tw]

Absolutely great thread, incidentally... :D

[tlarkin]

This thread has once again inspired me to learn some higher level programming. Looking at obj C right now since it can be bridged in languages like Python.

[Hal Itosis]

Well... if anyone's still interested: i did notice that the popup menu at the top of the panel doesn't seem to function. (it's supposed to display the hierarchy above the current directory).

:)

[Touchstone64]

This thread saved my bacon. I've been trying to crack that nut for I-don't-know-how-long. Thanks to all posters :)

[renaultssoftware]

This thread saved my bacon. I've been trying to crack that nut for I-don't-know-how-long. Thanks to all posters :)

This thread might make it onto the Macosxhints website.

[regulus6633]

I'm really glad to see all of the interest in my original post of the call method usage. We can extend applescript's capabilities greatly with this tool.

However, I'm wondering how I can access Core Foundation functions in the same way. For example, NSString has a method stringByReplacingPercentEscapesUsingEncoding:. I can easily use that in applescript. I found this method lacking though and wanted to use the more basic Core Foundation method CFURLCreateStringByAddingPercentEscapes() for greater control. I couldn't figure it out so if anyone knows how to access that type of function using "call method" from applescript I'd love to see it.

[renaultssoftware]

If there were a way to create a run-time object, perhaps… just thinking…

[Red_Menace]

You can't call any of those C functions from the new AppleScriptObjC, either. In Xcode, you can work around it by using an Objective-C wrapper, but I don't think you can get everything linked together using plain AppleScript. You could probably write a small command line tool that calls the function and include that in your application bundle, though.

[regulus6633]

Thanks for pointing that out Red Menace... about AppleScriptObjC. I don't use that so I didn't know. I know how to make command line tools so that is a solution but I was hoping for an easier way when I just needed quick access to one function. Oh well.