>Arrays would be good for passing multiple parameters to and from an
>external.
Tuviah,
I envisioned that there will be several parameters available just like in
old times, just not in a fixed-size C-style-array but rather using
accessors (think of the param() and paramCount() functions). Here's a C
example how an XCMD could look:
void main( XCmdBlockPtr xRef )
{
char myString[256];
if( GetParamCount( xRef ) >= 1 )
{
GetParamString( xRef, 1, myString );
// now do something with it.
}
else
SetReturnValue( xRef, "Error: Too few parameters." );
}
>I tend to think that manipulating the structure of an object should be
>MetaCard's job. In my external I have the user pass the data of a field
>instead of the field itself, because I've seen many SC externals which
>break in MetaCard because the external made callbacks to a SC field or
>graphic.
This is because it wasn't implemented in a platform-safe manner. HyperCard
and SuperCard use the MacOS-specific TextEdit record, but to do this
cross-platform, we'd have separate callbacks:
GetFieldText - retrieves raw text w/o styles
GetStyleRun - retrieves one style run (reference) by number
GetStyleRunStart - gets the start offset of a style run reference
GetStyleRunStyles - gets the text styles of a style run reference
>>but should we also allow data types?
>No, this only complicates matters. Strings can be converted to numbers
>easily enough.
You are right, it can cause complications. However, we could provide a
little kind of 'framework' for XCMDs by providing calls that do the
conversion for them. And since the format of the parameter block would now
be private to the host, the host could store parameters as something else
than strings, thus possibly saving conversion time. For this purpose, we
could offer a GetParamType() callback. Hosts that want to stick with
strings would simply hard-wire this callback to return the string type.
>As for raw data the the size of the parameters, should be
>passed along with the parameters to the external.
This will certainly need to happen. We could provide a callback to convert
it to a string, though, which will be what's still desired for most uses, I
guess.
Cheers,
-- M. Uli Kusterer
------------------------------------------------------------
http://www.weblayout.com/witness
'The Witnesses of TeachText are everywhere...'
