All DatabasesMacTech Vol 06-1990
HyperCard 2.0
Volume Number: 6
Issue Number: 11
Column Tag: XCMD Corner
HyperCard 2.0
By Donald Koscheka, MacTutor Contributing Editor
The Revolution
Thomas Jefferson once stated that “Revolution is that event which allows all
ordinary events to continue”. Based on this definition, I’m inclined to feel that
HyperCard 2.0 is a bit revolutionary. For the past 3 years, stack developers have
expended a tremendous amount of energy trying to squeeze the last bit of performance
from HyperCard.
This effort almost always leads to the development of some suite of XCMDs to
supercharge an existing stack. As I watched this evolution develop, I noticed that
XCMDs typically fall along a specific set of tasks. These include file I/O, interfacing to
external devices, print management and window management (including dialogs).
From the perspective of the XCMD programmer, the HyperCard 2.0 revolution is not at
all subtle: HyperCard incorporates many features found previously only in XCMDs.
HyperCard 2.0 brings more to the party than new XCMD capability but in keeping
with the spirit of this column, I will focus on what’s new in the XCMD world.
What’s New and What’s Not
Whenever you need to develop for a new version of any software package, you
need to evaluate the scope of the update. You can perform this evaluation very quickly
by asking yourself two questions: “What changed since the last version” and “What
hasn’t changed since the last version?”
Armed with these two questions, the best place to find the answers is in the
interface and library files in HyperCard 2.0. My version of HyperCard 2.0 came with
just 3 files: HyperXCMD.p, HyperXCMD.h and HyperXlib.o. I was immediately
surprised to find that XCMDGlue was missing from the distribution disk. At first I
thought this was a mistake but a quick disassembly of HyperXLib.o showed this not to
be the case; XCMDGlue is no longer needed, that function is now performed directly in
the Callback Library.
So the first change is that we no longer need to compile our code with a glue
routine. The interface code varies incrementally beyond this point (that is, they’ve
ADDED stuff but all of the old stuff is still intact). For example, XCMDs are still called
with the same parameter block record as in earlier versions of HyperCard with the
exception that the the fields in the block take on special meaning for external windows.
External windows adds a whole new dimension to HyperCard so look for a lot of
discussion about them in future installments of this column.
The parameter block is not only used for interfacing between the calling script
and the XCMD but also for interfacing between the XCMD and the HyperCard callbacks.
The callback engine has been increased to over 75 callbacks (I counted two callbacks
that appear in the library but are not documented as of this writing). The new
callbacks can be divided into groups according to the class of services they perform:
Hypertalk utilities, Memory Utilities, String Utilities, String Conversions, field
utilities, miscellaneous utilities, Creating and disposing windows, window utilities,
text edit utilities, script editor utilities, debugging tools. The categories are Apple’s,
not mine. I will use this list to set the agenda for this column for the next several
months. We will look at each of these categories in detail in turn.
One of the most salient additions to XCMDs in HyperCard 2.0 is the addition of
“version control” information. From now, whenever the user passes ! as the first
parameter to an xcmd, you need to return the version of that XCMD. if the user types
passes ? as the first parameter, you should pass usage information to the user. This is
straightforward and simple enough to abide by. Funny how those darned “command
lines” have a habit of appearing in the most unusual of places. With this in mind, we
will start at the beginning again, introducing “Simple XCMD 2.0.c” with this new
twist. This is the building block for all 2.0 XCMDs and you can use it as a sort of
template. A controversy will no doubt arise over the hard coding of strings in the
XCMD code resource, but without a lot of thought, I think that you can convince
yourself that there isn’t a better way to do this.
An XCMD For 2.0
While we haven’t answered both questions in great detail on this pass, we have
learned enough to jump right into trying our hand at an XCMD for 2.0. We learned that
the interface is pretty much unchanged and that old XCMD should work fine under 2.0
although they won’t be able to take advantage of 2.0’s features. Most importantly, we
learned that this isn’t a complete restart; we can easily build on existing experience as
we migrate our code to 2.0. This is good -- nobody likes to spend 3 years doing
anything just to discover on such and such a date that everything they know is wrong!
Listing 1 is a sample HyperCard 2.0 XCMD. It is quite straightforward since it
doesn’t actually do anything. I am taking the introduction of HyperCard 2.0 as a rare
opportunity to “wipe the slate clean” and start all over again with a fresh look at
XCMDs. Since this is the first of many columns in which I will discuss 2.0, I have
decided to start off slow and sure and build from here. Listing 1 conforms to the
structure of a 2.0 XCMD without relying on the new XCMD glue. If you don’t have 2.0
yet, you can build and test this XCMD under earlier versions of HyperCard until you
get version 2.0. I did this to allow those of you who want to follow along with this
column to get caught up first. I will start in earnest on 2.0 next month. Until then,
Happy Hacking!
/**********************************/
/* File: Sample.c */
/* */
/* A sample XCMD for Hypercard */
/* 2.0 */
/* */
/* Well-behaved XCMDs for HC2.0 */
/* will respond to the ! and ? */
/* requests by returning version */
/* and usage information */
/* respectively. */
/* */
/* ---------------------------- */
/* ©1990, Donald Koscheka */
/* All Rights Reserved */
/**********************************/
/*
Project:
ANSI-A4 -- standard “C” libraries assembled
off of register A4
MacTraps
Sample2.0.c (contents of listing 1)
Set Project Type:
Type == XCMD | XFCN
Name == SimpleXCMD
id == 1000
Usage
SimpleXCMD “?”
SimpleXCMD “!”
put the result
OR
Put simpleXCMD( “?” )
Put simpleXCMD( “!” )
*/
#include
#include
#include
#ifndef NIL
#define NIL (void *)0L
#endif
Handle strToParam( str )
char *str;
/***************************
* Given a pointer to a string,
* copy that string into a handle
* and return the handle.
*
* The input and output strings
* are both null-terminated
*
***************************/
{
Handle outH = NIL;
long len = 0;
len = strlen( str );
if( len )
if( outH = NewHandle( len ) )
BlockMove( str, *outH, len + 1 );
return( outH );
}
pascal void main( paramPtr )
XCmdPtr paramPtr;
{
Handle answer = NIL;
char *str;
long len;
paramPtr->returnValue = NIL;
/** The first thing that a well-behaved **/
/** HC2.0 XCMD should do is check to see **/
/** whether the first (and only) parameter **/
/** is the user request for information or **/
/** or usage information. If so, just pass **/
/** your answer back to the user, otherwise **/
/** go ahead and perform your xcmd services **/
if (paramPtr->paramCount == 1){
if ( **(paramPtr->params[0]) == ‘!’ ){
paramPtr->returnValue = strToParam(“Simple XCMD, version 1.0,
©Donald Koscheka, 1990”);
return;
}
if ( **(paramPtr->params[0]) == ‘?’ ){
paramPtr->returnValue = strToParam(“Simple takes no parameters
and does nothing with them.”);
return;
}
}
}
Listing 1. SimpleXCMD.c
Referenced by (16):