XCMD Limitations

[Yennie at aol.com]

I think there are pretty much two options here.

One is to recode as a native MetaCard external- this is not hard to do, the 
only things that change are a) callbacks and b) parameter parsing and return 
values. If the XCMD is written clearly (i.e. one parameter parsing block of 
code and a generic routine for building the return value), this is usually 
trivial. I've managed to write code in the past that compiles as XCMD or 
Metacard-native based on a couple of #ifdef's.

The only other options I see would be to carefully recode the callbacks. What 
callbacks exactly does it use? I find there is almost never a compelling 
reason to use any callbacks that you couldn't code yourself instead. The 
exception with Hypercard of course was their external windowing code. That 
you won't be able to replicate without wholesale changes to your approach.

One suggestion if you decide to stay with the XCMD: try taking your copy of 
HyperXCmd.h and commenting out the prototypes for all of the callbacks. Now 
recompile and you should get an error for each one. From this you should be 
able to compile a list of the callbacks used. The simple ones are trivial to 
replace: StrToRect, StrToNum, etc. In fact, they'll run faster if you just 
call the appropriate C function instead.

If you are really stuck, you'll probably need to post some actual code to get 
much better suggestions. If you'd like and you can, send me something 
off-list and I'll look it over.

HTH,
Brian

> Thus far I've managed to avoid writing a single external since I started
> working with MC in '97 (I hired out the only one I couldn't make in native
> MetaTalk), so my knowledge of how MC works with externals is very limited.
> Hopefully somone with experience with this can take a moment to fill in the
> details... 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.runrev.com/pipermail/metacard/attachments/20021024/28c278ec/attachment.htm