HyperCard Headstart, Part One

by J.R. Mooneyham

ORIGINAL PUBLICATION DATE: SUMMER 1994
_______________________________
_______(Free JavaScripts provided by The JavaScript Source)_______



(Translate this site)

First aid for broken links


| Search this site | Site map | Site author | Site store |
>>> | Latest site updates | <<<

| Access Google's cache of this site |


Alternative (mirror site) links
| Translate this site |
| Site search | Site map | Site author |
| Access Google's cache of this site |

Introduction



HyperCard Headstart is meant to help bridge the gap between absolute novice and moderately experienced scripter; a gap which might otherwise prove difficult for some users of HyperSavvy v1.0 (the companion stack to this piece) to surmount. Although presented in the format of a separate stack from the magazine, and made available on America On-Line as a separate download for user convenience, HyperSavvy is an integral part of the FLUX Summer 94 issue; so if you don't have it, you only have roughly half of this issue of FLUX.

HyperSavvy v1.0 is powerful template stack, brimming with scripts and techniques useful to serious stack developers. However, HyperSavvy probably qualifies as being in the intermediate to advanced level in regards to scripting instruction; ergo, the purpose behind this article.

All this being said, this article is not intended to substitute for the HyperCard User manual or other reference texts. It is solely designed to provide beginning scripters with a look at HyperCard through the eyes of an experienced scripter and programmer, in an attempt to hasten their personal progress, and help them better exploit HyperSavvy specifically, and HyperCard in general.

If there's any discrepancy discovered between the explanations given in HyperSavvy, and those given here in the Headstart series, let HyperSavvy have the final say. Why? Because in HyperSavvy the scripts are "live", so if I overlooked something, or momentarily forgot a bit of syntax in my writing of the instructions there, the malfunctioning script would instantly get me back on track, causing me to correct my error. Here in this article though, I can offer you only the same level of accuracy other articles or books on the subject do, since there are no live scripts to call my attention to flaws in the text.

Those of you familiar with other references on HyperCard, or even for other programming languages, will recognize what I'm talking about. It's not unusual for a user to find a script or program listed in a text to be flawed or incomplete, due to some detail overlooked by the author. Even in the best of texts, like Danny Goodman's HyperCard Handbook series, users will occasionally type in a script from the book only to find it doesn't work as it's supposed to. The problem is the thousands of details in syntax, and the non-digital nature of the human mind. For example, not long ago I found I was typing
lockscreen
in this piece when I should have been typing
lock screen
. What's the difference? HyperCard has no idea what the first version means, when it's used as a standalone command; it requires the space in the middle to understand what I'm talking about. And yet, in the second way of setting that value, by saying set the lockScreen to true, it is proper to leave out the space! See how easily I or any author can cause you possibly hours of frustration with the tiniest lapse in memory? We try to minimize such things, but it could literally require the rest of our lives to insure that every last mistake was squeezed out of a book or large article like this one-- so if we did everything possible to make these things absolutely perfect they'd never be published in time for you to use them! This article won't be worth squat 25 years from now, because everything will have changed so much. Heck, it may be obsolete just within a year or two, if something extraordinary happens among Mac authoring tools. So all I or any author can do is give you the most and best we can, as quickly as we can-- and hope you'll forgive our human errors.

In order to get hands-on experience with the levels of HyperCard discussed here, a user will require either the HyperCard Development Kit from Apple, or an issue of FLUX magazine, issue Summer 94 or later, along with HyperCard Player 2.1.

This article addresses HyperCard from the standpoint of version 2.1-- two versions older than the latest currently available (2.3). There's a few differences between the versions that will directly affect some of the instructions given here-- but not much. For example, v2.2/2.3 makes it slightly easier to create default buttons in stacks; not a great leap from the technique described in the Headstart articles. As for the hoopla over the added animation and color capabilities of 2.2/2.3 compared to 2.1, well, the reader will see by the end of this series many reasons why those elements may not be very important to a great many stack developers; at least, not as important as a HyperCard compiler, or across-the-board platform compatibility would be.


HyperCard's strengths



HyperCard is a powerful, high level, visually oriented programming language. By powerful, I mean you can often create in weeks a simple application that could require months or years in another environment. By high level I mean the syntax is much closer to plain english than many other programming languages. By visually oriented, I mean HyperCard is heavily slanted towards visual presentation, or a GUI (graphic user interface).

Object orientation. Virtually everything you do in HyperCard is oriented towards the modification or description of a particular object: a button, a card, a text field, etc. Almost any object in HyperCard can possess its own script, or separate program. This fact usually makes it much easier to develop, debug, and understand a HyperCard program than is the case with many other languages.

Development speed. As mentioned before, many kinds of programs can be completely developed and released in HyperCard format before they even get out of the planning stage in another language.

The learning curve in HyperCard may offer the gentlest slope of all high level programming languages available today. The gentle slope means scripters rarely must endure the same levels of frustration other language users do, while learning. But be forewarned; this is a relative comparison only; that is, other languages are often so awful in this regard that they can make learning to speak Japanese seem easier. So when I say HyperCard offers the easiest learning curve in existence today for high level languages, that's like saying it's better to be shot with a .22 caliber pistol than a .45-- the real difference may not seem like a lot at the time, for beginners. No matter what language you commit yourself to learning, there'll be some pain and anguish involved. I guess the best way to say this is that HyperCard is to programming what the Mac is to personal computing; both are far from perfect, but both are also a lot better than the alternatives available at the moment.

HyperCard is an industry standard for multimedia authoring tools- - and as such is king of the hill in add-ons and the size of the knowledge base in general. For several years one of Autocad's chief advantages was touted as its position as the industry standard-- which meant it enjoyed the greatest third party support in add-ons and overall knowledge base concerning CAD usage. HyperCard itself enjoys many similar advantages in its own domain, with literally thousands of different stacks available, many offering up new and unique scripting techniques, XCMDs, and XFCNs, as well as numerous reference and instructional texts, and even magazines (like FLUX) which all serve to expand and deepen HyperCard's potential usefulness and accessibility to everyone.

Almost every Mac user is potentially a HyperCard user. Since its inception, HyperCard has been bundled (in one form or another) with virtually every Mac sold. For the first few years, the bundled HyperCard was the full-blown, programmable version, which greatly encouraged the development of applications and other types of stacks. After that, Apple begun bundling only a runtime version of the program-- HyperCard Player-- and selling the programmable version separately. The initial wide and free availability of the full HyperCard helped create the current industry standard position of the program, and spawn similar high level language efforts on the other major computer platform-- Intel based PCs. It also made HyperCard the highest level, highest capacity, and most flexible universal document exchange system for any personal computer platform, period. Not until the mid nineties did any other universal document software even begin to approach HyperCard's status in this area. As of this writing (June '94), no other product (on any platform) yet matches HyperCard's circulation, library of compatible documents available, and power and versatility offered to developers/ authors in the environment.

HyperCard's power can be expanded or extended with add-on modules developed in other languages. Those versed in other programming languages like C, Pascal, or BASIC can expand upon HyperCard's basic feature set by writing external commands or functions for their stacks (XCMDs and XFCNs). In other words, your HyperTalk program can delegate certain tasks to other language programs as desired for reasons of speed, or special capabilities.

HyperCard runs exclusively on the Mac. Later in this piece, this same element is listed as a weakness. But it's also a strength. Because Apple's long held insistence on Mac interface guidelines, among other things, have made the Mac the closest thing to a 'plug'n play' personal computer around, which means users will rarely have to walk through a mine field of technical problems in order to get to your software, as they might on an Intel-based machine. One aspect of this is that when writing a script to do something like a custom print job, the same script will likely work with practically any printer a Mac user might have attached to their machine. If you were developing on an Intel machine, you might require dozens (even hundreds!) of different scripts, each dealing with a different possibility in the printing department-- and still there could end up being thousands of users for whom your program would not print correctly. Microsoft and other developers have been striving heroically to remedy such situations on the Intel machines for years now, with some success. However, you have only to examine typical articles on real usage of the systems by people like Jerry Pournelle in BYTE, or others, to see the substantial difference that still exists between the Mac and Intel platforms, across-the-board.

HyperCard's weaknesses



While the learning curve in HyperCard is not very steep, it can be as long as that of any other programming language. Before, in listing HyperCard's strengths, I mentioned the gentle slope of its learning curve. The flip side of that is the total time required to reach complete mastery of the language, which may be about the same as that required for any modern computer language-- though those users with a natural talent for visually based programming may enjoy a significant edge in attaining expert status.

Low end graphic output. As of versions 2.1 through 2.3, HyperCard is heavily biased towards monochrome video output-- and low resolution output at that, at 72 DPI (dots-per-inch). It also uses a default screen size of 512 x 342 (the screen dimensions of the original Mac). While this makes virtually any stack display compatible with almost any Mac ever made, it also severely limits HyperCard's (and so stack authors') capacity to exploit the display capabilities of newer Mac systems. This shortcoming is gradually changing, with successive HyperCard versions; 2.x may support card sizes several times larger than the 512 x 342 of bygone days, as well as support various QuickTime operations dealing with TV-style video; 2.x also added some badly needed support for color and grayscale images in stacks-- though this support is not yet of the caliber most scripters might expect.
HyperCard's future surely will include more advanced imaging capabilities and flexibility. This aspect of HyperCard's future may be more certain than any other.

Little or no support for object-oriented graphics and mid-range to high end animation. HyperCard's built-in support for object-oriented graphics is almost non-existent; a shocker when you consider how object-oriented the language is in other ways. This grave restriction extends to animation capabilities as well, leaving stack authors little choice but to use QuickTime video for such things, as restrictive and inflexible as that is for many purposes. What little HyperCard offers in true animation power amounts to little more than screen-flipping, automated painting, and programmed manipulation of buttons and fields (toggling visibility of icons and text, and changing sizes, shapes, and positions). The dependence on bitmap graphics (as opposed to object-based images) also means a bigger appetite for storage space on disk than might otherwise be the case, and thus is partly responsible for the big disk area many stacks often require. Of course, part of this big disk footprint is due to the overhead involved in any program file as versatile and user-friendly as a HyperCard stack can be.
As expansion of animation powers and support for object-oriented graphics are often closely related, any change in either will tend to boost the other. As one of HyperCard's stated reasons for being is multimedia, it's difficult to imagine it remaining as limited in animation and object-based graphics as it currently is, for much longer. Plus, the arrival of the Power Macs should make such expansions a lot more feasible from Apple's point of view.

Slow execution speed and lack of compilation capabilities . These elements are closely related, as a compiled HyperCard stack would be a lot faster in execution than is presently the case. Computer languages come in two flavors: compiled and interpreted. BASIC and other high level programming languages have traditionally been interpreted, primarily because compilation of their more user-friendly elements required substantially more effort on the part of language developers than the closer-to-machine talk elements of languages like C. This has begun to change in recent years, as developers obtained more powerful tools and techniques with which to tackle the complexities involved. Unfortunately, HyperTalk remains an interpreted language today, although some third party tools such as Compile It! from Heizer Software are gradually taking on the job. All compiling would do is permanently translate the close-to-English format of HyperTalk to the almost incomprehensible gibberish of assembly code. Such assembly code makes it a lot easier for your computer to complete the translation to its own preferred lingo, which looks a lot like "10101011010010101". As amazing as it may seem, your computer can run your program a hell of a lot faster as "10101011010010101" than it can in the form
go to next card
. Interpreted languages, on the other hand, force the computer to do a 100% translation of your program to its own language of ones and zeros each and every time your program runs. See the difference? A compiled program is already mostly translated, so the machine zips happily through it, at near to its maximum speed. With an interpreted program however, first the computer must go through the painstaking process of translating it, and then and only then do what the program instructs it to-- for each and every statement in the program. Compiled is close to one-step, interpreted is possibly many steps. What's the difference in perceived execution speed between the two? Maybe as little as 100%. Maybe as much as 3000%! So a compiled HyperCard would be a much more capable and versatile HyperCard. But we don't have a compiled HyperCard, so stacks which perform tasks even moderately complex can slow to a crawl in relation to user perceptions. For this reason, few truly ambitious projects (such as advanced artificial intelligence programs) are undertaken in HyperCard today. To be fair, however, it is possible to write special purpose XCMDs and XFCNs, as described above, to speed up particularly slow procedures in HyperCard, by directly using compiled code or something similar. Possible? Yes. Practical and easy? Often no. Remember, you'll need expertise in some language other than HyperTalk to write your own XCMDs, etc.; or else find one from a third party that does what you need.

The speed limitations on HyperCard may become moot as Mac hardware gets faster and more powerful. Too, there may be full scale compilation in HyperCard's future, if Apple decides to make it a more integral part of their system software.

Restriction to a single platform. HyperCard is exclusively a Mac language and development environment. This means anything you produce with HyperCard will only work and be accessible for Mac users. Since Macs account for only some ten percent of all personal computers today, this means your HyperCard-based products will only be applicable to ten percent of the computer-using population. This limits your potential market and audience.

Limited choices in some important lower level parameters and capabilities. Like most other high level languages, HyperCard suffers from a variety of utilitarian limitations-- some a direct result from the high priority placed on ease of use and rapid development time. For instance, HyperCard possesses little flexibility in the types of files it can produce. Basically, you have only a choice of the standard stack file, or a pure text export. Recent upgrades to HyperCard have extended this somewhat, but not by much. If your application calls for a highly custom file format, you'll have to resort to XCMDs and the like to do it with HyperCard-- in other words, you'll have to use another language entirely.
Apple is hard at work on maximizing cross-platform compatibilities in many aspects of its operating system; why not HyperCard too? This may well happen, if only indirectly, through the OpenDoc standard. So this restriction may not stand very much longer, either.

Weakness in variable arrays and other database type functions. HyperCard also suffers weakness in the areas of variable arrays and certain other variable references you might be accustomed to using in other languages, like BASIC. This shortcoming can have significant impact on capabilities like large database manipulation or artificial intelligence programming.

The purchase price of the HyperCard Development Package. For any other development package as powerful as HyperCard, sporting a street price of roughly $100, this would not be listed as a weakness, but as a strength. For virtually all development packages require purchase. But Mac users have long memories, and the programmable HyperCard began life free, bundled with all new Macs sold. So those familiar with history may be excused for seeing the purchase price of HyperCard as a liability today. Fortunately, the price is not tremendously expensive-- yet. As HyperCard becomes more powerful the price may inch its way up to less acceptable levels. So what about those users who'd like to dip their toe in HyperTalk, but aren't planning anything ambitious enough to justify purchase of the development kit? Luckily, there's another choice: using the Magic palette, which makes its debut in this issue (Summer 94) of FLUX. With the Magic palette users may create, move, and resize buttons and fields, as well as examine and modify their scripts, and various property settings. In other words, the FLUX Super Stack offers users its own mini version of the HyperCard development environment-- for free!

Large disk space overhead and potential compatibility problems. A final weakness of HyperCard stacks comes from their dependence on a runtime module or the parent HyperCard application being present on a computer in order for them to run. This is related to the topic of compilation mentioned earlier, in that a compiled program would require no such help. This necessity for a runtime module or the parent application means an additional 750K or so of disk space is required, beyond the space necessary for the custom stack itself. It also means that users can purposely or accidentally remove the HyperCard application from their disk, rendering non-standalone stacks unable to run. Since HyperCard itself is not an integral part of the Mac's operating system, it can be deleted or erased like any other application, thereby making that particular Mac incompatible with any HyperCard stack that requires the parent application.
As discussed earlier, such problems as these may vanish if Apple integrates HyperCard more fully into its operating system, which it may well do. The substantially greater power, speed, and storage space available on newer Macs today could handle it easily, and the flexibility such a move would add to Apple's system software, and the support of stack developers, would be of considerable competitive value for the company. At the moment this void is filled partially by the free availability of HyperCard Player with new Macs, and version 2.2/2.3's capacity to produce standalone stacks (essentially attaching a full-size HyperCard application to a stack-- a stop gap measure for the moment, until something better may be done).

HyperCard's different levels of user difficulty and access


Most of us have had at least a bit of experience with video games. In that entertainment form there will often be several different levels of difficulty the player may tackle in the course of a game. HyperCard too possesses varying levels of difficulty, where both programmers and users are concerned.

1. The easiest (but most restricted) level is browsing, or level one. Any stack set to this level will not permit a user to do much of anything beyond simply looking at the pictures and reading the text displayed within a stack. The user will be able to click buttons to obtain some additional functionality, if such has been previously programmed into the stack by its creator, but that's it. Browsing level is good for stacks which should be read or seen, but not changed in any way.

2. The next level (level two) is typing. This level is suitable for database style stacks, allowing users to type new information into the stack, and perform searches of information in the stack. Anything else, such as creating images or programming, is not allowed at this level of access. Successively higher levels always include all the capabilities of the levels that preceded them; so level two is essentially level one with the ability to type in additional information as desired.

3. Level three is painting. Here a user may not only move through the stack, reading text and admiring pictures, as well as type in new information, but also add to or change the images they find there. Level three is the highest level available in the stripped down version of HyperCard bundled with new Macintoshes these days, called HyperCard Player. Full blown HyperCard applications, which allow the higher levels described below, may be purchased separately. An alternative to such purchases is obtaining a FLUX Super Stack equipped with the FLUX Magic palette, which offers access to many of the capabilities of HyperCard's userLevels 4 and 5, free of charge.

4. The fourth level is authoring, which adds to level three the ability to create new buttons, fields, cards, and therefore interface screens, but only a bare minimum of programming capability to enliven these objects. Specifically, about the only programming you can do at level four is instruct a button to move the user to a different card when clicked upon.

5. Finally there's level five, or scripting. Level five is the whole enchilada, the entire shebang, offering you all the power you're smart enough to squeeze from the current version of HyperCard. Level five gives you access to the programming language of HyperCard, called HyperTalk. Wherever I list actual program code in this series, it is in the HyperTalk language.

The Biggest Problems in Getting Started Scripting with HyperCard


1. Your number one problem may be getting hold of the programmable version of HyperCard,

since it's no longer bundled free with all Macs. However, this obstacle is not a large one, since the programmable HyperCard is usually available for a street price of around $100 (from mail order discounters). If $100 is more than you can chew at the moment, consider the latest version of the FLUX Super Stack, usually available free or at low cost from a variety of sources.

2. Your second biggest potential problem getting started with HyperCard will be an unfamiliarity with the Macintosh interface in general.

If you're not accustomed to icons, buttons, menus, palettes, and your desktop and finder, you'd best stay out of HyperCard until you are. Diving into HyperCard authoring or scripting is like going up another level in the general Macintosh GUI (Graphical User Interface). If you're not yet accustomed to the lower levels of Finder and desktop, you'll probably have problems in scripting or authoring in HyperCard.

3. Your third biggest potential problem will, ironically, be the solution to the second

-- that is, after you've become familiar and comfortable with your Macintosh interface, and how most of its programs work, you'll discover some inconsistencies inside HyperCard. For example, your Mac's Finder will often require you to click twice on some icons to activate them, yet in HyperCard only one click will usually be desirable.

4. Another perhaps unexpected item will be HyperCard's automatic saving of changes.

HyperCard saves the latest changes every time you move from one card to another, or perform other typical actions in the program. This can interfere with some of your normal back up habits and expectations in that vein. It also reduces the flexibility for those users accustomed to depending on a lack of file updates as a last resort "Undo" capability. With most Mac applications you can back out of all the file changes made since the last manual save command, either by selecting a "Revert" command in the File menu, or quitting without saving, and then reopening the non-updated file. With HyperCard this technique generally won't work, as your stack is updated as a background process, rather than manual save. While this maneuver can be desirable for some novices, or those customarily lazy about updating files (since it should reduce the risk of lost work), it conflicts a bit with the practices of knowledgeable users with experience based on more primitive computer technologies (even on the Mac, most mainstream applications still require manual save actions these days). The way I personally deal with this idiosyncrasy is to perform any manual saves desired by moving to another card in the stack, and then back again-- this forces one of HyperCard's automatic saves to take place. As for the ability to revert to a previous state of the stack, my own personal backup practices almost always allows this, no matter what HyperCard or any other application does in regard to saves (This is fully explained elsewhere). Luckily, updating object scripts in a stack during editing of same is much more conventional in nature (with actual "Save" commands), thereby avoiding the strangeness of the more general stack save operations.

5. Compacting.

In order to deal successfully with the many complex elements involved, HyperCard stacks require periodic compacting to reclaim space no longer needed on disk, due to changes. Compacting, unlike saving, is not performed automatically unless you specifically instruct the stack to do so (via script). If you neglect compacting on a regular basis, you run a greater risk of suffering a "corrupted" stack, which could cause you to lose important work by eventually refusing to function properly.

6. The next few problems in getting started are the same as with any new programming language-

- unfamiliarity with language syntax, understanding how to create (and stop) repetitive loops, and providing the meticulous level of detail a program requires to function.

All programming languages, including HyperCard's HyperTalk, require that programs or scripts be written from a particular perspective. The perspective rules are:

A. Your program is a list of instructions; a 'how-to' manual of sorts. It is meant to explain to a very young person-- about 6 or 7 years old-- how to perform a certain task.

B. Any comments in your code are meaningless to the child-- comments are for your use only, and will be ignored by the child.

C. In your instructions, you must use words and processes with which the child is familiar. In every case, the child is a prodigy in the computer language you're working in, but knows little of normal english language conventions and phrasing. Your primary avenue of communication with the child is the child's own language-- and so the burden of correct syntax and phrasing falls wholly upon you-- not the child.

D. Your instructions must be highly detailed, explaining every nuance of what you expect the child to do. The child has a perfect memory and will forget nothing you tell it, but it also will follow your instructions to the letter-- even if that letter turns out to be obviously mistaken upon execution.

E. In 99.9% of the cases, any and all problems you encounter getting your instructions across to the child will be your own fault; for this particular child is a model of discipline and logic, and damn near perfect in how it follows its instructions. The child is utterly non-emotional, and will do even the most repetitive of tasks millions of times without complaint; only the instructor's own mistyping, lack of effort, or misunderstanding of the child's vocabulary will be the source of problems in most cases.

Initiating and ending repetitive loops

Repetitive loops in HyperCard are a lot like those in BASIC, but more convenient and relaxed in syntax. Here's a sample loop in a HyperTalk handler, profusely explained via commented lines (HyperCard ignores anything after two dashes and a space character):

[NOTE: please forgive the strange formatting below; it's very difficult to get script formatting to carry over correctly from HC to a word processing document, for some reason]

      on mouseUp
      	global totalLines
      	--  below i will be the counter, or the variable
      	--  the loop uses to keep track of how
      	--  many times it's cycled through its instructions
      	put 1 into i  -- here I provide the first value for the counter
      	repeat until i > totalLines
         	-- above I tell the handler to keep doing this until
         	-- the value of i is greater than the value of
         	-- the global variable totalLines
         	-- which I declared above that I planned to use here
         	   add 1 to i -- here I add 1 to i; if I fail to do this I get
         	-- an endless do loop- a definite no-no in programming
         	-- the counter i variable is the only way the loop has
       	-- of knowing that time is passing; so if i is not
         	-- incremented time stands still inside the loop
         	-- leading to the loop continuing to run unless
         	-- some value involved becomes too great
         	-- for HyperCard to swallow, and it crashes
         	-- or the user manages to abort the loop somehow
         	-- such as with a reset of their Mac or pressing the Apple
         	-- and period keys simultaneously (this last might not always
         	-- work- it can be disabled in a script, for example)
      	end repeat
      end mouseUp



Just to make things clear, below is the same handler shown above, only without the comments:

      on mouseUp
         global totalLines
         put 1 into i  
         repeat until i > totalLines
         	add 1 to i 
         end repeat
      end mouseUp

Another problem relevant to all programming languages is that beginning programmers might be dismayed at how much work it requires to get their program to accomplish apparently simple tasks.

Some frustration in this area is pretty much inevitable for everyone, novice and expert alike, as most of us will tend to muddle our way through with a minimum of manual references, with few of us capable of successfully guessing at the syntax and vocabulary of the language we're using. These two things will result in a lot of useless or obscenely lengthy code, as well as script errors-- if you can get the program to run at all that way.

Sooner or later anyone seriously interested in programming will acknowledge the importance of the manuals, and make use of them, while everyone else will give up entirely.

Programming is definitely not for the closed-minded or weak of will.

As mentioned elsewhere, you should try to modify already existing scripts to serve your purpose, in many cases. This practice will save you enormous time and effort, as well as teach you a lot.

Start with a script that already works. Then make only small and limited changes, fully testing the script for flaws in execution immediately after each change. If errors are found, deal with them immediately, rather than postponing-- or worse yet, proceeding to add still more code to the already malfunctioning script.

Religious back up of incremental versions can be worth its weight in gold. Only recently I witnessed an excellent example of this, when I discovered an awful bug in code I'd thought damn near perfect. A quick examination of the script and consideration of error information revealed no obvious fix, so I began backtracking through backup files in search of the last working example of that particular part of my program.

I was shocked to find out how deep into my backup library the last working example was-- over 40 versions back! Of course, the error had slipped by me for that long because I'd failed to test the script immediately after a very minor script change, and for the next 40 plus versions I was working on a different area of the program entirely, satisfied that all else was in wonderful shape. Just how close did I come to NOT having a working version of that bit of code still in my library? There were around twenty older versions than the last functional file; so I retained a significant safety buffer even 40 versions deep. But still, it was much too close a call, considering the importance of that particular project.

Fortunately, my own method of backing up stacks has never yet let me down. Here's how I do it, in case you'd like to do the same...

One User's Low Cost, Comprehensive Back up Method:


Every two or three minutes... I update the stack I have open at the time by moving to another card and back again, or saving the current script I have open via the File menu.

Every five minutes... I compact the currently open stack.

Every ten to fifteen minutes... I create a new incremental version of the stack. Incremental versions of a stack like HyperSavvy might have looked like this on my disk:

HyperSavvy.34
HyperSavvy.33
HyperSavvy.32
HyperSavvy.31
HyperSavvy.30

(I almost always view my files in my Mac Finder "By Date", so that the latest versions are usually near the top of the list).

At the same time I create a new incremental version on my hard drive, I copy the previous version to a floppy for backup. When the floppy gets full, I store it in a box labeled "HyperSavvy v1.0 Pre-Release", placing the disk in the front of the box-- so latest versions are always near the front, older versions towards the rear.

It might surprise you to know that I don't usually label individual floppies in my incremental backup library-- I don't have the time or energy to spare. Plus, affixing a label to a disk pretty much ruins its flexibility, since labels are difficult to remove.

How exactly do I index my backup floppies?

I have a big cardboard box, about 1.5 feet wide, 2.5 feet long, that sits with its narrow side to the front on a sturdy platform near my computer. The walls of the box are maybe 7 inches tall-- or about 2 inches taller than a floppy disk. There's another large piece of cardboard I use for a dust cover over the backup box, that roughly matches the dimensions above, but is just a bit narrower and shorter, with edges along the sides that fold down and slip inside the side walls of the box below when the whole contraption is closed.

Inside the large box are maybe 48 original cardboard floppy disk boxes-- or their bottom halves, anyway. Most of the boxes contain around 10 disks each. There's a bit less than a dozen major backup libraries in my really big box, with a lot more minor ones. A major library might be composed of several floppy disk boxes, with newer backups towards the front, older ones to the rear. In the very last box bringing up the rear of a single library column, I'll have a piece of paper sticking upright, from behind all the disks it shares the box with. This paper is about 4 inches square, and has scrawled on it the name of that particular backup library.

The result of all this is when I raise the dust cover I have instant access to full backup libraries of virtually every ongoing project in my life.

How deep do I let incremental backup files get on my hard drive?

This depends on how large the program I'm working on is, as well as the size of the hard drive itself. Ideally, if I had Gigabytes to play with, I'd let incremental backups pretty much pile up all the way from version one to final release. But given real world conditions, a program currently in development and roughly one percent the size of my entire hard drive (one Megabyte), might get as deep as ten incremental versions on my main drive-- though that would be pushing me pretty hard, since I rarely have more than six to ten Megabytes free at any one time.

The smaller the file is, the more lenient I am in how many live backups I allow myself to keep. If only half a Megabyte in size, I might keep twenty incremental versions handy on my hard drive.

How deep do I allow my incremental backup library on floppies to get?

At this moment I have several projects under development, with attendant backup floppies in my library. The number of floppies backing up a particular file changes drastically after that program sees public release. Release means the latest version of that software passed every conceivable test, and so very few (if any) known bugs are present in the latest version. That version is archived in at least three separate floppies, and placed in a fire proof safe. Then, the rest of perhaps dozens of disks that might form the incremental backup library are placed in a box marked as "disks ready for recycling". The backup files on them are replaced as needed with backups of a new ongoing project, and the floppies then placed in the appropriate new library box. In this way practically my entire library of incremental backup floppies eventually gets recycled. To get an idea of how deep I allow incremental backups to get, I have a handy example of a stack about 225 K in finished size, that within the last week (of this writing) went into general public release. There's 24 floppies containing incremental backups of the stack, with each floppy averaging around five different versions held. This makes for a total or roughly 120 incremental versions available to me near the end of the developmental cycle, for that particular product-- or nearly every single version ever created, from the first to the last. To accomplish the same depth with a much larger stack, like an issue of FLUX magazine, a lot more floppies would be required-- almost one floppy per each incremental version, as the issue nears completion. So sometimes I match this depth with larger stacks, and sometimes I don't; but I like to try.

Because there's nothing I hate worse than losing a significant amount of work-- and that's exactly what happens if your backup library is inadequately maintained. Not might happen-- will happen.

As I have mentally blocked out the event due to its horrific nature, I can't recall many of the details. But I do know that once, many years ago, I lost some three to four months of grueling computer work in less than sixty seconds-- because I was not adequately backed up.

Most users have to endure a personal disaster of some sort to become reasonably disciplined in matters of backup. I sincerely hope you are not one of this majority.

What about catastrophic insurance for my backup libraries?

What happens if a fire in the computer room melts my libraries, or a tornado comes and blows them all away, or a thief steals them?

First of all, I periodically deduct a single disk from the backup library of a currently open project, to store it in an entirely different room, away from the office. A bit less frequently, I put the latest versions of all projects currently in development into a fireproof safe (switching them out with any predecessors of their ilk). Then, of course, when a project is completed and going into general release, I archive three copies of the final version in this same safe.

In addition to all of the above, the latest versions of all our software will usually be on computers belonging to my associates as well, transferred either by modem or sneaker net, for possible testing or other purposes-- but also as an additional form of backup. Most all these machines are miles away from one another, so the chances of all copies being zapped simultaneously are low.

Finally, there's the distribution copies of the software, that go out to direct customers, user groups, shareware distributors, CD-ROM publishers, and the like. And copies uploaded to services like America OnLine. Through these channels copies stream out to literally thousands of users like yourself-- a few of which would probably be glad to send me back a copy of my own program if they learned I was in dire straits.

If God really took a disliking to me I could lose access to all these backups, one way or another-- but I try not to tick Him off in such a manner.

Using tiny test bed stacks to develop a script before installing it into your main stack.


Sometimes your main project stack may be getting pretty large, and therefore cumbersome to easily make incremental backups of. And yet, that's precisely the conditions under which you require incremental backups the most, as a single bad bug cropping up could delay the project's release for months. Or, the particular script you're working on may be getting complex, and difficult to debug within the main stack itself, with all the distractions of other handlers and such present. In both these cases it may be wise to copy the problem script from the main program, and paste it into its own tiny test bed stack to grow for a while.

The advantages of this are many. One, you'll be able to much more easily, cheaply, and quickly make incremental backups of the developing script. Two, you won't be endangering your major project as much with the necessary trial and error. Three, you'll suffer far fewer distractions as you attempt to make the script work.




Forward to HyperCard Headstart, Part Two


The above article(s) come from and make references to a collection copyright © 1993, 1994, 1995, 1996, 1997, 1998, 1999, 2000, 2001, 2002 by J.R. Mooneyham (except where otherwise noted in the text). Text here explicitly authored by J.R. Mooneyham may be freely copied and distributed for non-commercial purposes in paper and electronic form without charge if this copyright paragraph and link to jrmooneyham.com are included.

So who is J.R. Mooneyham, and just what are his qualifications for speculating about the future of government, business, technology, and society?

You can find out by clicking here...(and also send FEEDBACK)


Back to the Table of Contents of the Signposts Timeline

Back to J.R.'s WebFLUX Page (the magazine)

Back to J.R.'s WebWork Page (A hefty catalog of links to almost everything)

Site Map for the WebFLUX and WebWork pages