This was a tool for an early role-playing game. And looks it.

My second programming job out of college started as a HyperCard stack. HyperCard was an amazing tool not just for programmers, however, but especially for the weekend programmer or even the weekend non-programmer. It didn’t require any programming to get started. Just put some text placeholders on a background card, some buttons, maybe add a pre-created action to a button such as “move to next card”, and you had a very simple visually-oriented application that responded in a manner customized for you and your data.

There were a lot of non-programmers who used HyperCard and graduated to weekend programming. Because after you wrote your text or placed your graphics or added a button with a standard action, if you wanted to add code to that object, you could. You might start with slinging messages from object to object, or performing simple math on one of the text placeholders.

HyperTalk was not object-oriented in the sense that programmers mean when they talk about object-oriented programming. But it was object-oriented in the sense that programmers explain object-oriented programming to non-programmers. Every object on the screen could contain code that responded to specific actions. Each card could respond to keystrokes. A text box could respond to typing. Cards, text boxes, buttons, and images could respond to mouse actions. Keystrokes, mouse actions, and custom functions were all messages. And each object could send messages to other objects.

HyperCard was often used for databases; the card metaphor was especially apt for that. For example, I had a database of superheroes and supervillains in the Men & Supermen superhero role-playing game.

The game used meters, but clicking on the word “Height” on the character sheet would calculate and then display the character’s height in feet and inches:

“The short name of me” is the name of the text box; in this case, “Height:”. The code deletes the last character to get rid of the colon, so that it can ask for the value of the field named “Height”, which is the field that contains the actual height in meters. In fact, it contains a phrase, such as “1.75 m”. Word 1 of that is “1.75”.

Like many interpreted scripting languages, HyperTalk converted freely between numbers and strings, so that you can get word 1 of “1.75 m” and then immediately do math on “1.75”.

Messages bubbled up. If you sent a message to a text field, and the field didn’t handle that message, the message would bubble up to the card, to the background, to the stack. In the above code, Digits is one of those messages. It took the given number and returned it with that many digits in it. So that, for example, 1.21231 became 1.2, or .3593 became .36.

I stored the Digits function in the overall stack; as long as no intervening object contained a Digits function, the Digits message would bubble up to the stack and perform that function.

Similarly, each of the four die icons on the main page rolled dice; the dice-rolling script was in the stack, not in each die image. The six-sider with three pips rolled three six-sided dice using this code:

The Dice function looped through each of those numbers and rolled them as dice.¹

In some ways, HyperTalk was even more intuitive than AppleScript. Thirty years later, and I still occasionally try to use the HyperTalk syntax of “add number to variable” when I’m writing an AppleScript.

You can see these functions work in HyperCard Simulator. Choose “edit simulator script” and then “show the message box”. Then paste the Dice function or the Digits function into the “simulator script”. In the message box, type Dice(“10,10,10”) to roll 3d10, or Digits(5.151233, 2) to convert a number that is a long string of digits to a shorter string of digits, rounding in the process.²

What brought me down this memory lane is that I just discovered Pierre Lorenzi’s HyperCardPreview which allowed me to open up my Men & Supermen character database and see the characters as well as the underlying scripts. It doesn’t run stacks, but it does allow viewing the cards as they last appeared.

It was very easy to create databases without even thinking of them as databases, but rather as sequential documents, such as a series of character sheets.

There is a serious story behind this character that I don’t remember at all. “When he broke his clone out of Project Prometheus”?

Now that I’m able to see these cards again, I wanted to make sure I don’t lose them again, by taking a screenshot of every card in the stack—that’s 161 cards (four backgrounds, but a whole lot of Men & Supermen characters). Sadly, HyperCardPreview itself is not scriptable. But AppleScript’s System Events can script it.

The basic logic of this AppleScript is:

1. Use System Events to get HyperCardPreview’s window position and size.
2. Repeat for each card, using the current card number and total number of cards from HyperCardPreview’s window title.
3. Use /usr/sbin/screencapture to capture the screen area covered by HyperCardPreview’s window position and size.

Enable the script menu inside of Script Editor’s preferences.

Paste this into Script Editor, save it as an application, and call it something like “Capture All Cards”. Use Script Menu while using HyperCardPreview to open the HyperCardPreview scripts folder, and drag or save the script there.

The script uses Do Shell Script to call screencapture on the command line to perform the screen capture. Using System Events to take the screenshot turned out to be troublesome. While I was able to get it to screenshot the correct window using cliclick to move the mouse and System Events to type the correct keystrokes to invoke screen capture, all of the screenshots ended up on the Desktop without any identifying name.

I also considered using JXA, because it would have made parsing the title easier. I’ll have more about JXA vs. AppleScript for this task in a later post.

HyperCardPreview also allows saving the stack as a JSON file, with all of the data and scripts intact as text. This file can be iterated through with any scripting language that supports JSON, such as Python or Perl. If you still have any old HyperCard stacks lying around, I recommend exporting now, whether you think you’ll need the data later or not.

Open HyperCardPreview’s script menu from the script menu.

Capture All Cards needs to be saved as an application, so that you can grant it permission to control applications on your computer. At various points macOS may ask you to grant Capture All Cards or Script Editor access to control your computer. That’s necessary for System Events to work. I’ve found that if you later edit an AppleScript application, you’ll need to manually remove it from both the Accessibility list and the Screen Recording list under the Privacy pane of the Security & Privacy settings. It no longer has permission³ but macOS doesn’t ask to add it.⁴

So whenever you update the script for your own purposes, delete Capture All Cards from both of those lists, and then drag the app back in via the Finder. You can display the app in the Finder from the Script Menu while using HyperCardPreview if you saved it there.