ADVERTISEMENT

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<SetUpA4.h>
#include<string.h>
#include<HyperXCMD.h>
 
#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 )
 XCmdPtrparamPtr;
{
 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