RE: Feature request to solve a problematic AppleScript behavior with raw Apple Event codes
RE: Feature request to solve a problematic AppleScript behavior with raw Apple Event codes
- Subject: RE: Feature request to solve a problematic AppleScript behavior with raw Apple Event codes
- From: has <email@hidden>
- Date: Fri, 22 Oct 2010 21:25:12 +0100
Scott Babcock wrote,
I'd like some a way to tell the compiler to leave Apple Event codes
in their raw form. My off-the-cuff suggestion was to wrap such codes
in back-ticks (e.g. - `<<class from>>`). This would enable scripters
to handle esoteric scenarios like the one in my example, but it would
also enable them to work around terminology conflicts in which more
than one Apple Event code is associated with a particular "friendly"
keyword.
Your example poked in AS's privates, so tough cookie there. If you want
to do exotic stuff, there are more powerful, non-naughty ways to do it
(osaxen, appscript, AEM/OSA APIs).
As for terminology conflicts, as Ed says those are fairly rare and
better dealt with by fixing the problem at source. Broken APIs are
broken APIs, and the third-party ones aren't really Apple's problem. On
the long list of issues that Apple should be addressing I'd say this one
was very low.
Regards,
has
--
Learn AppleScript, 3rd edition, Sanderson & Rosenthal:
http://apress.com/book/view/9781430223610
Control AppleScriptable applications from Python, Ruby and ObjC:
http://appscript.sourceforge.net
_______________________________________________
Do not post admin requests to the list. They will be ignored.
AppleScript-Users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
Archives: http://lists.apple.com/archives/applescript-users
This email sent to email@hidden