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
On May 26, 2012, at 2:42 AM, Peter wrote:
> 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 prev
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
Ken,
thank you very much for your enlightening and in-depth explanation! This is
what I hoped somehow to receive back in February...
Over the next days I will try and put your approach to practice. If it works as
I hope I will certainly withdraw my comment about the new API being a
half-baken
In partial rehabilitation of the Scripting Bridge, I should add that it
certainly makes life A LOT easier than using NSAppleScript when pulling out
data from a scriptable application: just try to make sense of the
NSAppleEventDescriptor NSAppleScript returns, even given the flaws I pointed
out
On 26/05/2012, at 8:24 PM, Peter wrote:
> In partial rehabilitation of the Scripting Bridge, I should add that it
> certainly makes life A LOT easier than using NSAppleScript when pulling out
> data from a scriptable application: just try to make sense of the
> NSAppleEventDescriptor NSAppleScr
Am 26.05.2012 um 13:07 schrieb Shane Stanley:
> On 26/05/2012, at 8:24 PM, Peter wrote:
>
>> In partial rehabilitation of the Scripting Bridge, I should add that it
>> certainly makes life A LOT easier than using NSAppleScript when pulling out
>> data from a scriptable application: just try to
On 26/05/2012, at 10:25 PM, Peter wrote:
> On the other hand I have never seen/never tried to call AppleScript from
> Cocoa in AppleScriptObjC terms - if this wording makes sense at all. I don't
> remember reading about this in your book, which focuses of course on
> accessing Cocoa from AppleS
Thank you! You might want to add this to an appendix of your book some time.
Am 26.05.2012 um 14:58 schrieb Shane Stanley:
> On 26/05/2012, at 10:25 PM, Peter wrote:
>
>> On the other hand I have never seen/never tried to call AppleScript from
>> Cocoa in AppleScriptObjC terms - if this wording
On May 25, 2012, at 23:26 , Gerriet M. Denkmann wrote:
> But when the app restarts, it does:
>
> - (void)restoreStateWithCoder:(NSCoder *)coder
> {
> [ super restoreStateWithCoder: coder ];
> NSString *s = [ coder decodeObjectForKey: @"DisplayName" ];
> [ self setDisplayName: s
On 26 May 2012, at 23:03, Quincey Morris wrote:
> On May 25, 2012, at 23:26 , Gerriet M. Denkmann wrote:
>
>> But when the app restarts, it does:
>>
>> - (void)restoreStateWithCoder:(NSCoder *)coder
>> {
>> [ super restoreStateWithCoder: coder ];
>> NSString *s = [ coder decodeObjectF
On Fri, May 25, 2012 at 1:56 AM, Peter wrote:
> I'd like to reveal/select multiple items in the Finder.
> NSWorkspace only handles single files as in
>
> [[NSWorkspace sharedWorkspace] selectFile:currentFilePath
> inFileViewerRootedAtPath:currentFilePath];
>
On 27/05/2012, at 12:30 AM, Peter wrote:
> Just for clarification:
>
> This AS handler would then live in a .applescript file in my project wrapped
> in
>
> script ASClassInstance
Yes.
> And on of the above calls would live in a .m file containing
>
> #import //no need to put this in mai
13 matches
Mail list logo