Re: How do I make a singleton object AppleScriptable?
Re: How do I make a singleton object AppleScriptable?
- Subject: Re: How do I make a singleton object AppleScriptable?
- From: Matt Neuburg <email@hidden>
- Date: Mon, 21 May 2007 12:25:11 -0700
- Thread-topic: How do I make a singleton object AppleScriptable?
On Thu, 17 May 2007 10:51:30 -0700, Dave Camp <email@hidden> said:
>This seems like it should be easy, but I can't seem to find docs on it.
>
>I've got a single window utility app with a singleton controller
>object I'll call the EngineController. I want to provide AppleScript
>access to it such that an AppleScript could get or set one of the
>member variables.
>
>I've read the docs for adding scripting to a Cocoa app and I've built
>a .sdef file (based on /Developer/Examples/Scripting Definitions/
>Image Events.sdef) which defines my Engine class and a single read/
>write property called Mode. I added the "cocoa" tags so that it can
>use KVO to find my member variable. The sdef file seems to display as
>expected in Script Editor and I can compile a script for my app. This
>much seems okay.
>
>What I cannot figure out is how to tell the Apple Event manager (or
>whatever) that the in memory singleton EngineController object should
>be the target of events for the Engine class in my sdef file. There
>must be some way to associate the two so that the KVO access for my
>member variables works. I have so far been unable to determine how to
>link the two together.
>
>How do you do this?
Let's forget for a moment about the singleton EngineController object -
that's something happening behind the scenes, and is none of the AS
scripter's business. Think instead about how the AS scripter should see the
world.
It seems to me, from what you've said, that the answer is simple. You have
an application. It has a property. End of story. The fact that this property
really belongs, behind the scenes, to an "in-memory singleton
EngineController object" is irrelevant. That is something YOU know, not
something AppleScript knows.
So go ahead and add a property to your AppleScript "application" object in
exactly the same way you would normally do this. Let's say it's called
"prop" (since you do not say in your email what it is really called). Set up
the sdef accordingly. Let us suppose that in the sdef the cocoa key for
"prop" is "prop". Then go ahead and implement your category on the app
delegate, with methods "prop" and "setProp:". All done! It remains only to
write the code.
The fact that these methods "prop" and "setProp:" actually talk to your
EngineController object is irrelevant to Cocoa scripting per se (and
irrelevant to AppleScript absolutely). This would be very much parallel to
what's going on on p. 476 of my book, where we have an application property
"searchText". How we *really* access the searchText value when a request
comes in from AS to set or get the application's searchText is none of AS's
business.
m.
--
matt neuburg, phd = email@hidden, <http://www.tidbits.com/matt/>
A fool + a tool + an autorelease pool = cool!
AppleScript: the Definitive Guide - Second Edition!
<http://www.amazon.com/gp/product/0596102119>
_______________________________________________
Cocoa-dev mailing list (email@hidden)
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