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 <magn...@web.de> 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 <sstan...@myriad-com.com.au> >>>> 'AppleScriptObjC Explored' <www.macosxautomation.com/applescript/apps/> >> >> >> _______________________________________________ >> >> 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/dlyons%40lyons42.com >> >> This email sent to dly...@lyons42.com > > _______________________________________________ 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
