AppleScripting of Cocoa Applications
AppleScripting of Cocoa Applications
- Subject: AppleScripting of Cocoa Applications
- From: John Nairn <email@hidden>
- Date: Fri, 23 Jan 2004 08:48:07 -0700
If have been reading Matt Neuburg's excellent new book "AppleScript"
and it inspired be to revisit some of the problems I had making Cocoa
applications scriptable. It is all supposed to be easy and nearly free
and yet many things do not work for unexplained (at least in the sparce
documentation) reasons.
I defined the following class as shown by extractions from the suite
and the terminology
ResultSection = {
AppleEventCode = resS;
Attributes = {
name = {AppleEventCode = sNam; ReadOnly = YES; Type =
NSString; };
};
Superclass = "NSCoreSuite.AbstractObject";
};
ResultSection = {
Attributes = {
name = {
Description = "Name of analysis results section";
Name = name;
PluralName = names;
};
};
Description = "A Section of FEA or MPM analysis results";
Name = section;
PluralName = sections;
};
Although all features are recognized by the dictionary, AppleScript,
scripts always fail all attempts to access the "name" attribute with
the "informative" error message of
NSCannotCreateScriptCommandError
After much trial and error, I found two ways to fix it:
1. Change the "Name" in the terminology to anything except "name". For
example "get secName of section 1" works fine if the terminology
defines "Name" and "PluralName" as "secName" and "secNames". Although
this works, it prevents following the "natural-language" style of
AppleScript.
2. Change the AppleEventCode of the attribute to pnam. I am sure this
is the proper approach or that every attribute with "Name" = "name"
MUST have AppleEventCode pnam
Now perhaps this is a special case for "name" attributes, but it would
nice to read about such rules in documentation someplace. I read though
scripting of applications and could not find any rules or warnings. To
the contrary, the documentation says Cocoa applications will rarely
bother with these codes
From "Scriptable Applications":
Keywords are arbitrary names (stored as four-character codes)
used by
the Apple Event Manager to keep track of the attributes and
parameters
(described above) in an Apple event. Many Cocoa applications wont
need to interpret individual Apple events directly, so they
wont work with keywords.
But apparently certain keywords are important and must follow standard
practice otherwise the suite will not even work. Does anyone have a
list of such keywords or explanation of common settings? And what
happens if localized names are used? Is the AppleEventCode of pnam the
key (fix #2) or is the string in the terminology the key (fix #1).
Similarly, my application also has two types of documents and I have
tried many settings for AppleEventCode of each one and nothing works
completely. My current setting has the main type as docu and the less
common type as docR. The second document is crippled in AppleScript
support and the first type is sometimes confused with the second type
(e.g., "every document" returns both types and not just first type).
Making them both docu did not seem to work at all and making them both
non-docu also broke many standard AppleScript options for documents
(e.g. "make new document" stopped working).
------------
John Nairn (1-801-581-3413, FAX: 1-801-581-4816)
Web page:
http://www.eng.utah.edu/~nairn
_______________________________________________
cocoa-dev mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.