Accepting multiple types for a command parameter

Christiaan Hofman <[email protected]>
Newsgroups gmane.comp.macosx.devel
Message-ID <[email protected]>
I have script commands for which I want to accept multiple types for  
certain parameters. For instance, the parameter may be either an  
object specifier or a list of specifiers. More precisely, it can  
except either specifiers for some specific classes (that respond to  
the command) as well as either single generic (unspecified) specifiers  
and lists of generic specifiers.

Now my question is how I should best declare this in the .sdef. I  
should say that my app supports 10.5 and later. I know I need to use a  
bunch of separate <type> elements inside the <parameter> element.  
However I don't know what order to use and how specific I should get  
to make it reliably work on both 10.5 and 10.6. I am asking this  
because I've been trying various ways, and quite often under some  
conditions AppleScript does not accept the parameter. AppleScript is,  
as usual, far, far, far too picky. So I need to know how I should do  
it, and the docs don't tell me.

So I can think of four ways:
1. use <type type="specifier"/> and <type type="specifier" list="yes"/>
2. use <type type="specifier" list="yes"/> and <type type="specifier"/ 
 > (opposite order!)
3. use first the specific types and then use 1
4. use first the specific types and then use 2

I personally think that all four should always work, but in practice  
that is definitely not true, and what works seems highly dependent on  
the OS version. I know that on 10.4 none of these worked, and I had to  
drop support for the generic <type type="specifier"/> and force script  
writers to always wrap generic specifiers in an explicit list (even  
though I thought there was an automatic coercion specifier -> list of  
specifier).

So which of these four is the preferred / working way?

Thanks,
Christiaan
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.