We make software for humans. Custom Mac, Windows, iOS and Android solutions in HyperCard, MetaCard, and RunRev LiveCode
For the most part, almost all aspects of a HyperCard stack will convert to LiveCode with little alteration. There are a few things that are done differently in LiveCode, however, which always need to be modified. Most of the differences are due to the cross-platform capabilities of LiveCode that HyperCard lacks. For example, the Macintosh resource fork, while supported by LiveCode on Macs, is not available on other platforms. Therefore LiveCode provides alternate ways of handling color, pictures, sounds, cursors, icons, etc. For all of these, the resources are stored instead in the data fork of the stack, which all platforms recognize.
Issues which need to be addressed during conversion are:
In addition, the LiveCode compiler is much more particular than HyperCard in some areas of syntax. Function calls must always be preceded with "the" (as in the length of myString) or used with the parenthetical syntax (i.e., length(myString)). The longer English form will not work without the preceding "the". For example, length of myString will usually error.About LiveCode Menus later in this tutorial. A large part of this tutorial involves setting up and managing LiveCode menus, with a walk-through in the Adding a Menu Bar section.
The most common XCMD used in HyperCard stacks is AddColor, which provides a color overlay that HyperCard itself knows nothing about. Quite a bit of scripting is usually necessary to support color in HyperCard and colorized stacks generally have addColor calls sprinkled liberally throughout their scripts. Since color is built into LiveCode, none of those scripts are necessary and, in fact, will error repeatedly in LiveCode until they are removed. The best approach for handling colorized HyperCard stacks is to completely remove all addColor handlers and references from the scripts before doing the import into LiveCode. If you do this, the number of compiler errors you will receive from LiveCode will be substantially reduced, not to mention your frustration level.
Resources that are automatically imported and moved to the data fork during a LiveCode import include button icons, sounds, and cursors. Icons are automatically assigned to the correct buttons, and sounds and cursors will work when called in scripts. The conversion of these resources is transparent.Records Cards section, which duplicates one of HyperCard's Print Stack options.
While reserved words (words which are part of the language syntax) can be used as variable names in HyperCard, they are disallowed in LiveCode. The command:
will work in HyperCard but will error in LiveCode because name is a reserved word. It is best to develop the habit of customizing your variable names so that they will never be confused with reserved words, either now or in future versions of either program. HyperActive Software uses "the" before variable names for easy readability, i.e., theName. Many programers prefer a simple "t": tName. Any convention will do, as long as it guarantees a unique variable name. The best bet is to choose a convention that works for you and use it consistently.put field "last name" into name
A good guideline for constructing efficient variable names can be found (among other excellent scripting style information) at Fourth World's Scripting Style Guide.
This tutorial does not specifically deal with unquoted literals or reserved word variable names because our example stack does not contain any instances which would interfere with our conversion. But when converting your own stacks, you should look for and correct these items within HyperCard before importing your stack to LiveCode. You will receive fewer errors after the import if you do.