HyperCard Headstart, Part Three

by J.R. Mooneyham

ORIGINAL PUBLICATION DATE: FALL 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 |

Back to HyperCard Headstart, Part Two


Some possible HyperCard problems and how to deal with them


You need your stack to remember the values of a few global variables from one user session to another. But global variables have to be reinitialized each time the sack is opened. How can your stack remember something after the user quits?

Local variables, global variables, and parameters as described previously all have one thing in common: when the user quits from your stack they all get vaporized.

This can cause problems for a 'smart' stack, that's supposed to be able to learn and remember things from one user session to the next. How can you save and remember certain variable values? By putting them into some hidden text fields somewhere upon closing the stack, and putting the values back into the appropriate variables when the stack is reopened again.

There's several ways to do this. One, you can have a hidden data card the user never sees, which holds the data fields. Only you and your scripts need know about it. You prevent the user from accidentally stumbling across it by making your stacks navigation system only work with marked cards-- and leaving the data card unmarked (You set a cards 
marked
property in its Info dialog, and add the word 
marked
to scripts containing 
go
commands, like so: 
go to next marked cd.
)
NOTE: The 
marked
property helps you not only to discriminate about which cards a user sees, but about which ones they may print as well.

Two, you can hide the data fields by making them invisible, even if they reside on a card the user may see often. One way to hide them is to install an opaque, locked text field over the top of them, like a curtain.

Making your stack a high quality product
There's really only one way to do this-- and that's to mercilessly, tirelessly, relentlessly test your stack for flaws, under all possible circumstances, correcting immediately whatever problems you uncover. You do this until you can find no more problems-- and then you do it some more. You try to think up every possible way the stack might be used, every possible thing a user might do in the stack, and you try out every contingency. Finally, when you're dead certain the stack is flawless, a gem of perfection the likes of which the world has never seen before, you find a friend or family member willing to help you, and ask them to do their damnedest to break it-- to find anything at all about your project that doesn't seem quite right.

Nine times out of ten, if they're really trying, your volunteer tester will uncover a problem-- a serious problem!-- less than five minutes after they begin. I'm not saying this to be funny. Heck, it's not in the least bit funny when it happens! Except maybe to the tester, as they get to see the supreme confidence on your face shattered in an instant, with practically no effort at all on their part.

After your tester can no longer break the program, try to find another tester to try it. After the second tester has given it a clean bill of health, go through the program one last time yourself, as a user, rather than a programmer. Sometimes a few small flaws will become apparent to you at this point. Polish these off, then release your stack to the public-- encouraging folks to tell you about any problems they find with it.

Do all of this (and continue to correct any problems brought to your attention by users), and you have a good chance of putting out a quality package.
It also won't hurt if you use a stack or scripts based on HyperSavvy, to begin your project with-- because all those scripts have already been through some major debug sessions (and it still hurts me to think about them! Ouch!).

Minimizing the size of your stack

If you intend for a major route of distribution of your stack to be via telecommunications, you'll want it as small, compact, and efficient as possible.
Naturally you'll use HyperCard's Compact Stack command to squeeze the stack that way before release. And you'll compress the stack with a universally standard compression program for Macs, like Stuffit, before shipping it out-- maybe making it a self-extracting file so others won't need the Stuffit application to decompress it again.

If size is an issue, you probably won't want to use the standalone option in HyperCard v2.2/2.3, as this adds over 700 K to the size of your stack-- almost a whole 800 K floppy's worth! This will mean your stack will be dependent on users having a sufficiently new HyperCard Player on disk to run it-- but if your stack is based on any but the very latest version of HyperCard, most Mac users will either have such capability, or be able to obtain it pretty easily.

The addition of color or grayscale graphics, or sound resources, will make your stack huge in no time. If size matters at all, you must minimize the use of color, grayscale, and sound in your stack. Animation and video too can take up lots of space on disk, and don't really belong in a stack you want to keep slim and trim.

Let's assume you've no sound, animation, color, or grayscale in your stack. What other factors add fat to a stack? Fancy graphics and excessively wordy text both do this. Avoid all redundancy in text where feasible, and avoid purely gratuitous graphics-- imagery which really doesn't add much to the quality or functionality of your project. If you have a choice about using either text or graphics to inform the user about something, remember that the user would probably prefer the graphics, but text would usually take up less space on disk. If you decide you must use graphics, try to make them as small as you can without rendering them useless. Generally, the smaller the area graphics occupy onscreen, the less space they need on disk. Ergo, one excellent reason for HyperCard's (and the Mac's) widespread usage of small icons for many purposes.

You also want to avoid redundancy in your scripts. Remember that often many different objects-- buttons, fields, cards-- can all share the same handler, rather than each having their own individual copy. If you have 16 cards, all sharing the same background, and each contains buttons requiring a 
desperado
handler, put the 
desperado
handler in the background script and all will have access to it. If you have other cards requiring this handler, but they possess a different background, you can locate 
desperado
in the stack script instead of a background script, in order to make it available to all.

Another method similar to the last is to install a commonly useful button, field, or graphic in a background layer rather than card layer, so there's only one of them in the stack instead of many redundant copies.

Lots of different font, style, and size settings in your text fields will eventually amount to considerable extra space on disk-- as well as slow down the speed at which HyperCard may display the text in a scrolling field. There can be other problems brought about by excessive font usage as well, as described elsewhere in this article.

Don't allow unused cards, fields, or buttons to remain in your stack upon release. As these may be easily hidden from a user, it's tempting to keep them in sometimes, such as when they comprise an element of the stack you plan to implement in a later version. But where size is important, there must be nothing in a stack that's not immediately of use to that stack's purpose. You can't afford dead weight when your goal is a truly compact stack.

Speeding up script execution
Practically all scripters sooner or later will feel the need for speed, to use a quote from the film Top Gun . It's easy to slow down a script; much more difficult to speed it up. Here's a few tips that might help provide some acceleration:

Minimize redundancy within a handler. Oftentimes a scripter will unwittingly perform the same tasks several times in a lengthy script, such as calculating a certain value the script requires for execution. By rearrangement of code elements or other measures, such redundancies can usually be removed, thereby speeding up the script by ridding it of unnecessary work.

Minimize the use of text fields as containers for values used in speed critical scripts. Putting information into and retreiving information from text fields within a script is usually slower than doing the same with global variables, because the globals are in RAM while the text fields are accessed from disk.

Use the lock screen command. The 
lock screen
command described previously can help significantly in speeding up script execution, if one aspect of the script involves a lot of visually perceptible actions. 
lock screen
essentially turns off all graphic output, and so removes that processing load from the total burden of the HyperCard engine carrying out your script instructions.

Avoid use of the send command. Though the 
send
command is one of the more powerful HyperCard elements, using it can also slow script execution. So avoiding it speeds things up a bit.

Minimize the use of repeat loops. While repeat loops are recommended elsewhere in this article for saving storage space, offering greater programming convenience, and other reasons, they may be slightly slower in execution than a non-looping, straight listing of the commands. Nested repeat loops (one inside another), multiply the delay created. So minimizing the number of loops you use, or expanding them into straight script, may help in matters of speed.

Minimize the use of decision-branching. Another element that slows processing is the presence of decision points: if-then statements. Sometimes you can cut down the number of such statements by careful contemplation of what your script is doing, and why. Like repeat loops, nested if-then statements multiply the delays related to them.

Pre-process information where possible, wherever such information has an impact on a speed critical routine. This in effect will relieve part of the processing burden off your speed critical script, giving it less baggage to carry during execution. For example, if your stack navigation system must cope with a changing stack size by always knowing the location of a particular boundary card, have it get this information when the stack is changed by the user, and place it into a global variable for speed and convenience, rather than forcing the navigation routines to do the job themselves each and every time the user moves through the stack.

In some cases you may be able to effect a speedup by upgrading your version of HyperCard; because the newer version may allow you to do the same things in less script, and/or have had some of its critical internal processes tweaked a bit by Apple to run faster.

One last resort for speeding up your stack as perceived by users is simply to require a faster Mac platform in its specs. For example, if your stack simply won't run fast enough on a Motorola 680x0 machine, state that it requires a Power Mac in your promotional announcements and product descriptions.


Choosing your method of animation-- or whether your stack will contain animation at all
There's several ways to create animation in HyperCard. The most straightforward is 'page-flipping', wherein you simply move quickly through many screens, each only slightly different from its predecessor. This method has a lot of drawbacks, not the least of which are the huge amount of time that must be spent creating all the different screens, and the enormous expanse of disk space required to hold them. Less than one minute of page-flipping style animation in HyperCard might require a full Megabyte of disk space for the screens, assuming they are monochrome, or black and white in nature. Three minutes of black & white page-flipping, or a music video length, might be three Megabytes, which shows you how quickly page-flipping animation can grow to sizes too large for traditional distribution methods such as floppy disk. Change the format from B&W to 8-bit color or grayscale, and you expand the space required roughly eight times-- a one MB monochrome animation becomes an 8 MB color presentation.

There's a special trick you'd like to perform with your stack, but the prospect of writing all the necessary code is a daunting one. It'd be much better if this particular function was already included in HyperCard's repertoire. What to do?

First of all, make doubly sure that the function you want ISN'T in HyperCard's bag of tricks. Even if you've been working with your current version of the program for months, you could have overlooked several nice options in HyperTalk-- including the very trick you're after. Just remember that the trick likely won't be listed by the command you'd expect; look for several synonyms describing the capability you're seeking. Carefully peruse the user manuals and any other texts you possess, before starting on the trick yourself, from scratch. It doesn't make sense to re-invent the wheel if you don't have to.

Secondly, if you're an old hand like me, who's scripted for months or years in an older version of HyperCard before moving up to a much more modern and powerful one (I went from v1.2.5 to v2.1 in a single step), you may be wearing blinders and not even realize it. I personally smacked hard into several of the older HyperCard's limitations in the past, and so learned that certain avenues of development were effectively closed at that time. However, I've had to UNlearn several of those lessons, since upgrading. If you're not careful, habits learned from previous experience with older software will prevent you from using some of the new power at your command in an upgrade. ALWAYS make sure you really can't do something with a built-in HyperCard command, before running out and spending a month doing it from scratch. Life is too short for such unnecessary work.

Thirdly, consider the next item below...

Theres something special you want in your stack, that HyperCard just doesn't seem to offer. Should you create your own custom XCMD or XFCN for it?

First, make certain HyperCard doesn't offer what you want under a different command, function, or property setting than you expect, by thoroughly examining all HyperCard manuals and reference texts you may possess. Then search through everything that comes with the development package to see if something there (among the bundled accessory stacks) meets your requirements. Next, check out any CD-ROMs of stacks you may possess, to see if any show you a usable scripting technique to do what you want. Finally, look for XCMDs or XFCNs in other stacks, or online in a network library, for something already developed to perform the task required. If you find one, try it on for size to see if it meets your needs. If it does, contact the author about licensing it for use in your own stack, if necessary. Then, knowing what it does and what it'd cost to use it, balance the cost against your determination and ability to create your own, plus the time you figure it'd take to write and debug it, and go the way logic dictates. In many cases new scripters will find it more cost-effective to make a deal with an XCMD's author rather than try duplicating the code on their own, as most of us are not proficient in the arcane languages and resource management an XCMD or XFCN can require.

Choosing between color/ grayscale and monochrome imagery in your stacks
How much RAM do you have? How large is your hard disk or other primary storage device, and how much free space does it typically contain? What is the practical backup capacity of your system? All these questions are pertinent to your plans.

8-bit color and grayscale imagery require maybe 800% more of everything than comparable monochrome-based projects(!) More RAM, more disk space, more backup capacity-- even more processing speed. The minimum practical Mac system for development of purely monochrome HyperCard stacks no larger than one to one and a half Megabytes in size is probably a 16 MHz 68030 with 5 MB RAM and a 180 MB hard drive, equipped with monochrome video and a 1.44 MB floppy, as well as a versatile compression/ archival program like Stuffit Deluxe. This system also shouldn't be overly burdened with more than 40 or so installed fonts, or a System version later than 7.1. This is the minimum platform, and could be quite hard to live with, in a lengthy or complex development cycle.

What's the minimum Mac platform for development of 8-bit color or gray-scale HyperCard stacks, containing no substantial amounts of animation, sound, or video, and being no larger than four to five Megabytes?

A 33 MHz 68030, with 8 MB of RAM, 330 MB hard drive, 13-14 inch color monitor with 8-bit color video, 1.44 MB floppy, a color scanner, and a removable 100MB Iomega ZIP drive.

NOTE: Some users may howl at the maximum of 4-5 MB given here as the target size of the stacks to be created. However, a typical 8-bit color or grayscale screen could easily require a half Megabyte of disk space all its own-- so a 5 MB stack might only contain eight or nine substantially different screens-- a fairly low number for a stack, and so assumed close to the minimum size a developer might want to create. And any significant quantity of sound, animation, or video added to the mix would allow for far fewer dedicated interface screens than the 8-9 assumed here.

If your plans are a bit more ambitious than what we've discussed to this point, you'd best get something like a low end Power Mac, at the very least (the choice depending on the raw power and speed required), loaded up with 16-32 MB RAM and hard drives in the range of a Gigabyte, and a 100 MB ZIP or 1000 MB JAZ drive for backup, at the very least. If your goal is a LOT more ambitious than the above scenario, I hope you're rich-- because you'll need just about the biggest and best of everything that exists in the Mac universe today, just to get started-- $10,000 to $50,000 worth of equipment and software to get rolling, maybe more to actually complete your project-- IF you don't make any appreciable boo boos in purchasing along the way.

A corrupted stack.
The best way to deal with this is by taking preventative measures listed elsewhere in this article, such as frequently compacting the stack, and following a strict back up regimen with regards to incremental versions. If despite all these measures you still find yourself with a problem stack you must try to salvage, there's a stack called "Recover" from Apple which may be able to extract most or all of the more important elements from the damaged stack successfully [There's also Devil's Workshop v1.0, from me, which may sometimes be of service in these cases]. Some commercial file and disk recovery programs may also be able to salvage some of the problem stack for you. On the whole however, corrupted files are like venereal diseases-- minimizing the risk they pose to you before they occur is much preferable to dealing with them directly.

An infected stack.
Theres an excellent free anti-virus program called Disinfectant, the latest version being 3.5 as of this writing [3.6 as of early 1996], which will perform general purpose virus eradication of most applications and files, including HyperCard and its stacks. However, Disinfectant may often lag by a month or so in being able to recognize new viruses, compared to its most impressive commercial counterpart, Virex. Plus, Disinfectant has lagged still further behind in the area of detecting and eradicating HyperCard specific viruses which might be script based rather than more lower level in nature, as the majority of viruses are (most are lower level). On balance, most scripters could likely get by fine using a combination of Disinfectant and a HyperCard specific anti-viral agent (they're available online with AOL and other services), along with a bit of healthy caution in their daily activities.

SPECIAL NOTE: Please do not take any of this as criticism of John Norstad and his excellent program Disinfectant. Individuals like Mr. Norstad are certified Saints and Guardian Angels of all Macdom, not far below MacGods like Bill Atkinson himself, and have been a significant force allowing the Mac to survive and prosper as long as it has. Norstad's anti-viral system is provided free to all, and updated on a remarkably frequent basis, considering that such projects are somewhat afield of Mr. Norstad's main line of work, and wholly non-profit in nature. The program Virex, named above as sometimes doing Disinfectant a few viruses or updates better, is a commercial product, costing usually around $100, and so whose developers have tremendous incentives to stay ahead of Mr. Norstad in the virus competition. Indeed, it could be argued that the very existence of Norstad's free and extremely high quality Disinfectant is at least partly responsible for the quality and timeliness of updates displayed by Virex, as well as some other anti-virus programs.

I hope you will spend a moment contemplating Mr. Norstad's contribution to your happiness and mine.

Should you upgrade to a newer version of HyperCard before creating your stack?
Why might this be a problem? Because you could be upgrading yourself right out of the market for a year or more to come. In general, a product intended for wide release should be done in the oldest version of HyperCard which will support the practical development of same. The older the version of HyperCard you use, literally the more folks that will be able to use your stack. However, you should find a later version on which to test your stack's updating capacity as well, before release, simply to insure there's no problem with newer versions of HyperCard updating your stack to run with them (Newer HyperCards do this with a Convert Stack... option in the File menu).

Should you make your stack into a standalone application?
The newest version of HyperCard at the time of this writing (2.2) [2.3 as of early 1996] removes part of the reason for using older versions for development, with its capability for producing 'standalone' application versions of stacks. This allows you not to worry about what version of HyperCard a user has-- or even if they have no version at all. Because standalone stacks have their own run-time version of HyperCard attached to them like a hump on a camel, allowing them to operate regardless of the presence of HyperCard. This hump is substantial in size however, requiring around an extra 750 K of disk space above and beyond the size of your stack. This means if you plan to distribute uncompressed on an 800 K floppy your own efforts can be no larger than around 50 K-- a tiny size in HyperCard terms.

Uncompressed distribution on a 1.44 MB floppy allows you an additional 675 K of space for your own work (add the previous 50 K above to get a total of 725 K), which amounts to something on the order of the smallest FLUX issue ever shipped-- a prodigious amount of material for a lone programmer to create, or roughly the size required by a novelist wishing to distribute his book on disk.

With self-extracting compressed files, you can expect about a 30% size advantage, maybe more, or to be able to distribute stacks at least 30% larger than you otherwise could in the same disk space. Using self-extracting compression methods for distribution, you might be able to distribute 1100 K of your own work per 1.44 MB floppy, or 290 K per 800 K floppy, while making use of the 'standalone' option.





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