Re: Adding simple AppleScript commands to a Cocoa application
Re: Adding simple AppleScript commands to a Cocoa application
- Subject: Re: Adding simple AppleScript commands to a Cocoa application
- From: Scott Thompson <email@hidden>
- Date: Tue, 18 Apr 2006 21:37:12 -0500
On Apr 18, 2006, at 6:40 PM, Matt Neuburg wrote:
The last chapter of the second edition of my AppleScript book
contains an
example of implementing a "no-parameter command" (verb-first
dispatch). It
sounds to me, though, as if you're doing it right. The
implementation of
Cocoa Scripting and its curious variety of key-value coding
"slams" (as I
put in my book) "into your existing application like a side wind,
ignoring
your architecture and surprising your code". In other words Cocoa
Scripting
tries to militate against your nice object architecture. Basically the
problem you've cited is only the tip of the iceberg. Your solution
sounds
quite elegant considering everything. m.
"Slams... into your application like a side wind", boy isn't that the
truth.
I learned a few things in my recent foray into Implementing AppleScript:
• An AppleScript command may not be sent to the object that you think
you've set up to handle it
In many instances, I thought I had set up my sdef so that a command
would be sent to a particular class only to find that my code was
never called. In the end, I got into the habit of putting in
temporary, custom NSScriptCommand classes and overriding
"performDefaultImplementation" just to find out who received the
command.
This was particularly useful in the case of the "Move" command which
likes to figgle with the recipient object specifier. It took me a
bit of reading and thought to understand exactly what that command
did. (I was glad after I did figure it out though because it helped
me understand a lot more stuff)
• The AppleScript documentation is hard (for me) to read - I realize
that documentation is a very personal thing. For myself, I found
that the the Apple documentation spent a lot of time explaining how
Cocoa Scripting works, but that pedantry obscures the clear insights
that I needed about how to plug into the architecture.
• The "Make" command is the most frustrating command in the
universe. Make commands seem to be sent to the application
regardless of where you have command handlers installed. Having to
parse the object specifiers and re-dispatch the make command was
quite an annoying task.
The make command was particularly troublesome in my case because my
model objects were C++ (wrapped with Objective-C for the scripting
model) My Objective-C wrappers don't really work well until there is
a C++ object to back them up. The difficulty was that Cocoa
scripting is set up by default to create the Objective-C objects
directly. While this is generally a good thing, particularly
advantageous in Objective-C only applications, in my particular case
it was annoying.
While it took me the better part of a week to figure out how Cocoa
scripting "thinks", once I got the hang of it AppleScript through
Cocoa and the sdef was way was less painful than the Object Support
Library (OSL) mechanism.
Now that I know it's out there, I look forward to buying a copy of
your book :-)
Scott
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden