Re: creating your own commands
Re: creating your own commands
- Subject: Re: creating your own commands
- From: Shane Stanley <email@hidden>
- Date: Sat, 26 Dec 2015 18:05:15 +1100
On 26 Dec 2015, at 11:48 AM, Jon Pugh <email@hidden> wrote:
>
> I think that’s the majority of the rules.
To a point -- "use" statements can add an extra wrinkle.
Apart from what Jon said, Apple reserve all-lowercase values, and characters are limited to the MacRoman character set.
The issue, though, is what unique means. In theory, it means you can't repeat a value, and you can't use one of the values already defined by Apple (search for AERegistry.h for a list). But scripting additions can ruin the party.
When you add your terminology with a "use script..." statement, you're fine if you follow the above and what Jon said. But as soon as you add a "use scripting additions" statement, you also run the risk of collisions with codes defined by any loaded scripting additions (as well as their terms). And because scripting additions are an all-or-nothing affair, and because some declare so much terminology, and don't follow any particular convention, avoiding collisions becomes quite a bit harder.
The foolproof answer is not to include a "use scripting additions" statement, and to instead wrap any addition commands in "using terms from scripting additions". I suspect that's what the situation with scripting addition commands becoming effectively invisible when we add a "use" statement is trying to nudge us towards using. The problem is that it runs counter to what people are used to doing with scripting additions, and it's the sort of shift in coding I can't see happening any time soon. It's a pity, because it solves other problems scripting additions cause, too.
So unless you're happy to use/enforce that style, you really need to avoid codes that clash with any and all scripting addition commands your intended users might have loaded. Ugh. One good approach is to use one or more characters that are difficult to type in each code. As I said, it has to be part of the MacRoman character set, but in practice you'll find that most developers rarely stray beyond A-Za-z and space.
Shameless plug time: ASObjC Explorer has a built-in sdef editor that doesn't require the use of ASObjC. It warns if you enter a code defined by AppleScript or an all-lowercase code, and it won't let you enter illegal ones. It greatly simplifies creating sdef files -- you use menus and a table -- although nothing can remove the tedium. (You add a command in the bottom half of the document window, write the matching handler code in the top half, then hit compile to check it.) It's not perfect, but IMO it sure beats editing XML files directly. Especially as mistakes rarely result in other than complete failure.
--
Shane Stanley <email@hidden>
<www.macosxautomation.com/applescript/apps/>
_______________________________________________
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