Re: AppleScripting of Cocoa Applications
Re: AppleScripting of Cocoa Applications
- Subject: Re: AppleScripting of Cocoa Applications
- From: Don Briggs <email@hidden>
- Date: Fri, 23 Jan 2004 09:41:56 -0800
Hello, John
[1] This topic might be better addressed on the list:
email@hidden
and I'm double-posting THIS reply ONLY.
[2] Yes, this AppleScriptability stuff incurs lots of fussy details,
and the docs are sparse.
That's why we have Suite Modeler.
http://homepage.mac.com/donbriggs
(New version, 2.3.2 improves the rapid prototype code generation.)
[3] As long as NSCoreSuite is open as a document, Suite Modeler "does
the right thing" about
"name", 'pnam' (type in "name" as an attribute's name, and it suggests
'pnam' as the code)
"id", 'ID "
because Suite Modeler knows about conflicts of external names and codes.
The behavior is general -- it tries to steer you away from trouble with
conflicts, generally.
The key to success is to
open all the suites your suite will use (NSCoreSuite, NSTextSuite,
... as well as your own)
use the "Find" panel to find conflicts (works in free Demo mode)
[4] I don't have an example for you of a scriptable app with more than
one document type. Sorry.
(Cocoa/AppleScriptability newbies -- see my .Mac homepage above for
other examples.)
[5] You write:
Does anyone have a list of such keywords or explanation of common
settings?
Part of the answer is
AE/AERegistry.h
The other part of the answer is that I've not seen good docs on how to
APPLY this knowledge.
We're instructed to re-use these codes in AERegistry when appropriate.
But I haven't seen a doc that tells us what "appropriate" means in this
context.
Your example of two document types could serve as a test case for
Apple's documenters.
John, let's both look for replies on
email@hidden
and for new docs.
All best,
Don
On Jan 23, 2004, at 7:48 AM, John Nairn wrote:
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.
_______________________________________________
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.