Beginning HyperTalk: Making an External Index Stack

By Greg Raven
Volume 6 no. 7 (July 1988), page 13

The thing about HyperCard that really got me was the way you could Find anything in a stack by typing it into the Message Box. Suddenly, the restrictions of typical databases that had chafed so cruelly were but a bad memory.

Nevertheless, there remains the taint of a more ordered world. Perhaps it is cultural programming, perhaps too many days squandered in front of a card file at the library. Whatever it is, I still enjoy sorting my name and address stack.

With this as a given, it seemed but a short jump to create an index that would take me to the first card in each of the 26 alphabetic categories into which they were sorted. This might seem old-fashioned, but I was expecting to share this stack with other, non-computer types, and it made sense that the more familiar the stack looked the better it would be accepted. When I found that the Card Ideas stack had a graphic version of the traditional desk Rolodex, it seemed the ideal building block. Of course, indexes for other types of stacks may require different graphic elements, but the basic execution is similar for all.

Before starting to build the index, you must first decide which cards the external index will refer to. In the case of the name and address stack, there was no way of knowing that the current first cards of each letter (the first A card, the first B card, etc.) would forever remain the first card as other cards were entered. Therefore, I added 26 new cards, each with only a single letter of the alphabet in the first sort field. After sorting the stack, HyperCard placed these cards at the beginning of their respective categories. In other words, the first A card has only an A in the sort field, the first B card has only a B in the sort field, etc.

The second step was to create a new stack to serve as the external index. This stack has one card (showing the graphic of the Rolodex-style file) with 26 buttons, one each for the tabs on the graphic.

To connect the buttons on the external index stack to the correct cards in the name and address stack requires nothing more than using HyperCard’s LinkTo … feature. With the button tool selected, double-click on the button you wish to define. When the Button Info … dialog box comes up, click on the LinkTo … button. HyperCard will then display a window with three buttons labelled This Card, This Stack, and Cancel.

All that is needed to set up a link is to use the normal HyperCard navigational commands to get to the card or stack to which you wish to link up, and click on the appropriate button. In the case of the name and address file index, I started by selecting the A button, opening the name and address file, flipping through to the already-created card with the A in the sort field, and clicking on This Card. By repeating this process throughout the alphabet, I soon had an external index that worked nearly the same as the paper Rolodex file I had become used to.

The drawback to this system was that clicking on a button in the external index stack would take me to a blank card. Clearly, it would be better to go to the next card after the indexed card.

The first way of accomplishing this that came to mind was to use HyperCard’s openCard property. By calling up each index card in turn and inserting the following script at the card level, I was able to skip past the blank indexed cards:

	on openCard
		go to next card
	end openCard

The folly of this approach became apparent as soon as I decided to add some special effects to the external indexing procedure. Calling up the indexed cards in the name and address file would result in their immediately skipping to the next card, leaving no obvious way of rescripting, deleting, or even viewing the indexed cards.

Fortunately, HyperCard provides a way around this so my short script could be removed, but that left me once again staring at blank cards after using my external index.

The solution was found in the way HyperCard handles instructions in scripts. If the instruction cannot be executed at the level in which the instruction is found, the instruction is passed up the chain of command until a level is found at which the instruction can be acted upon.

Because there was already a link between the external index buttons and the matching indexed cards in the name and address file, it made sense to write a script in the external index stack. This decision was further supported by the fact that when HyperCard constructs a link, it does not hide the link somewhere in the internals of the program. Instead, it writes a small script for the linked button. By calling up the script of a button that has been linked to a card or stack, you will see HyperCard has automatically inserted a script that reads something like:

	on mouseUp
		go to card id xx of stack Phonebook
	end mouseUp

This script merely tells HyperCard to go to the linked card when the user clicks on the button. To get to the next card in the stack after the linked card, you need to add only one line to the script:

	on mouseUp
 		go to card id 21 of stack Phonebook
 		go to next card
 	end mouseUp

In this case, the go to next card instruction is given at the card level in one stack, but is passed up the HyperCard hierarchy to effect a change at the card level in another stack.

At this point, the external index works, but it is not very pretty. After clicking on the external index button, the indexed card flashes on the screen before the desired card is displayed. The solution was to add two more lines of script:

	on mouseUp
 		set lockScreen to true
 		go to card id xx of stack Phonebook
 		go to next card
 		set lockScreen to false
 	end mouseUp

Setting lockScreen to true tells HyperCard to freeze the screen display. This hides the effect of the next two script instructions from the viewer. Setting lockScreen to false turns on the screen again. The result is that after pushing the button on the external index, the next card you see is the card you want.