Re: Sending a list of path strings to the Finder via Scripting Bridge
Re: Sending a list of path strings to the Finder via Scripting Bridge
- Subject: Re: Sending a list of path strings to the Finder via Scripting Bridge
- From: Peter <email@hidden>
- Date: Sat, 26 May 2012 11:39:50 +0200
David,
thank you, but no, this will not work. I should have stated this explicitly:
'*** -[SBElementArray init]: should never be used.'
is the exception I get when using the method proposed by you. In my experience, all other alloc-init variants fail in the same way. It is impossible to alloc and/or init an SBElementArray.
(Posting this to the list, too, since it is a valuable addition to the discussion.)
Am 26.05.2012 um 11:26 schrieb David A. Lyons:
> I haven't tried it myself, but:
>
> <https://developer.apple.com/library/mac/#documentation/Cocoa/Conceptual/ScriptingBridgeConcepts/UsingScriptingBridge/UsingScriptingBridge.html>
>
>> For adding scripting objects to element arrays, you may use NSMutableArray methods such as insertObject:atIndex: and addObject:. To remove objects from element arrays, call removeObject: (or a related method of NSMutableArray) on the element array.
>
> ...so perhaps you can call +[SBElementArray array] to get an empty one and then add to it. Cheers,
>
> --Dave
>
>
>
> On May 26, 2012, at 12:42 AM, Peter <email@hidden> wrote:
>
>> Answering my own post:
>>
>> After much experimentation I come to the conclusion that this is impossible using Scripting Bridge.
>> Interestingly, a code example from Apple called SBSetFinderComment, which illustrates setting Finder comments using Scripting Bridge includes a "Reveal in Finder" function - for which it uses the method -[NSWorkspace activateFileViewerSelectingURLs:] Quincey Morris pointed out to me.
>>
>> The reason for this, as far as I can see, is a fundamental design problem, i.e. to my utter astonishment, there is no way to assemble a list of arbitrary paths as the target of an AppleScript command.
>>
>> (a) All AS elements have to be added to a SBElementsArray before you can work with them.
>>
>> (b) There is no way to alloc-init an SBElementsArray to add arbitrary elements to it.
>>
>> (c) Therefore you have to use one of the SBElementsArrays prepared by the Finder, i.e. [finder items] (see the code example above), which BTW, as it would in plain AppleScript, by default designates the items on the user's Desktop. There seems to be no way to specify any user defined folder (!) - see (f) below.
>>
>> (d) There is no way to delete the items from a given SBElementsArray and then add elements by the user's choice: [[finder items] removeAllObjects] will not clear the array, but instead move all items on your Desktop to the trash! (I consider this to be a bug.)
>>
>> (e) It is perfectly possible to reveal multiple items in the Finder. It is as simple as issuing [[finder items] reveal]. The problem is that there is no way to specify multiple arbitrary items: You can easily loop over an array of file paths, convert them to NSURLs (although Finder.h maintains that the URLs have to be NSStrings), and issue [[[finder items] objectAtLocation:theFileURL] reveal] - but this way the items will be revealed consecutively and not simultaneously. There are of course a lot of occasions where consecutive execution may be perfectly viable, but not here.
>>
>> (f) The Scripting Bridge talks at length about efficient coding using bulk operation methods. On the other hand, it does not even seem to provide a simple means to, say, access the elements from a specific folder X and narrow these down using filteredArrayUsingPredicate - with the exceptions of those predefined in the Finder sdef/Finder.h: i.e. the trash, home, startup disk, desktop and the like. For all other cases you have to access items individually and therefore inefficiently using objectAtLocation: or similar.
>>
>> This is an ugly mess. I am sorry to say so. I could not believe it, which is why I asked here. At least, Scripting Bridge was certainly not designed with the Finder in mind. It may work better for other scriptable applications, though. One more half-baked technology from Apple (as is the new pasteboard API in its current implementation even if it looks very elegant on the surface - I guess quite a good deal of people will be bitten by it if it becomes compulsory, since it prevents you from doing some simple things possible with the current API; see my inquiry on this list a couple of weeks ago). It is a shame that appscript can no longer be supported for current and future OSes. It is/was far superior.
>>
>> In the end I chose to use NSAppleScript using Shane's trick below and it turns out to be astonishingly fast and easy. (Even if it is supposed to leak memory.)
>>
>> Thanks for all your comments!
>>
>> Am 25.05.2012 um 09:31 schrieb Peter:
>>
>>> Am 25.05.2012 um 09:24 schrieb Shane Stanley:
>>>
>>>> On 25/05/2012, at 4:56 PM, Peter wrote:
>>>>
>>>>> If all fails I'll have to convert the path strings to hfs paths and string-assemble a script to run using NSAppleScript in code
>>>>
>>>> If you do end up using NSAppleScript, you can still avoid HFS paths: just use 'POSIX file "/Users/fred/whatever.txt"'.
>>>>
>>>> --
>>>> Shane Stanley <email@hidden>
>>>> 'AppleScriptObjC Explored' <www.macosxautomation.com/applescript/apps/>
>>
>>
>> _______________________________________________
>>
>> Cocoa-dev mailing list (email@hidden)
>>
>> 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:
>>
>> This email sent to email@hidden
>
>
_______________________________________________
Cocoa-dev mailing list (email@hidden)
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:
This email sent to email@hidden