HyperActive Software Home


Converting a HyperCard stack to MetaCard


Table of Contents

(Partial listing:)

Other MetaCard features

Like most programming projects, MetaCard stacks are never done. They can be improved and enhanced indefinitely. At some point the author needs to step back and decide, often arbitrarily, that the project is finished -- and so we have done with this tutorial. There are many other things we could have added to Tech Support TimeSaver, but we hope this tutorial provides enough incentive for you to discover them yourself.

With that in mind, we'll finish with a brief list of a few other MetaCard features that HyperCard users may not be familiar with, and which you may want to explore.

Global variables versus custom properties

MetaCard supports custom properties, which open up a whole new way of storing and managing variables and data. SuperCard users are familiar with custom properties, but it may be a new concept for HyperCard users. A custom property is a property that the stack author creates and assigns to an object. A custom property is stored with the object and is permanent; it is saved with the stack and persists after quitting. A custom property can be named anything you like, as long as you do not use a reserved word, just as you can name a variable any way you like. Custom properties are a good way to save data in a stack without resorting to some common HyperCard tricks, such as putting it into a hidden field or hiding it at the top of a script.

In our example stack, there are several global variables that track the use of the timer. These globals are initialized on openStack and store information about whether the timer is open or closed, paused or stopped, and so on. These globals could be eliminated and replaced with custom properties that store the same information. The custom properties could be attached to the stack, or to one of the timer cards or buttons. Which object stores the custom property is up to you.

To define and set the value of a custom property, you simply use it, the same way you simply put something into a variable to create it. Suppose we wanted to replace the stack's gTimerOpenOrClosed variable with a custom property instead. Custom properties are set rather than having data put into them. The syntax would be:

set the timerOpenOrClosed of card "timer2" to "closed"
This would create a new custom property called timerOpenOrClosed, which would be a custom property of the "timer2" card. Whenever you wanted to read its value:
get the timerOpenOrClosed of card "timer2"
The value of timerOpenOrClosed can be retrieved by any script without the need to keep it in memory like a global variable. Whatever value the custom property contains when the stack is saved will be there the next time the stack is opened. If the property is one that changes frequently during stack operation, it is a good idea to initialize it before using it the first time, just as you would a variable. If the values do not change during stack operation, then initialization is unnecessary.

Reading custom properties is somewhat slower than reading global variables. If you have many of them to read all at once, or your scripts need to read some values repeatedly, globals may be a better choice. But if you have only a few, or if your stack only needs to read each one occasionally, the persistance and convenience of custom properties is indispensable.

One example of custom properties occured in a multi-lingual stack that HyperActive Software created, in which button names needed to be displayed in various languages depending on the user's preference. Each button was assigned a custom property called userlanguage. The contents of userlanguage was a list of lines, each containing the name of the button in a particular foreign language. Before each card opened, a script looped through the buttons, setting the button label to line x of the userlanguage of btn y.

The Tech Support TimeSaver stack could easily be altered to use custom properties.

Frontscripts and backscripts

Frontscripts and backscripts are another SuperCard feature supported by MetaCard. A script can be stored in any object, and inserted into the message hierarchy when needed, either in front of all other objects in the hierarchy, or behind them. A script inserted into the front, for example, could catch all mouse events on a card before they arrived at the card. This might be useful if you are scripting the use of painting tools and you want to substitute different behaviors for your stack's usual mouse events. When the user switches out of a painting tool, the stack could remove the frontscript and the normal mouse behaviors would resume.

A script inserted into the back catches messages just before MetaCard does. At HyperActive Software, we routinely insert a backscript into the message hierarchy every time we launch MetaCard (our Home stack has a handler that does this.) The script we insert contains all the custom handlers we've written to help with common development tasks. In HyperCard, these scripts were housed in a stack which was placed in use, a feature MetaCard also supports. The difference is that backscripts receive messages after they pass through the Home stack, whereas stacks placed in use receive messages before they reach the Home stack, as they do in HyperCard.

Resizeable windows and geometry management

MetaCard stack windows can be displayed in all the modes supported by the running OS, including dialog (modal,) document, palette, modeless, iconified (on Windows,) and maximized/minimized (windowshade on Macs, task bar on Windows.) Resizeable stacks have a size box on Macs, and on Windows will resize from the edges and corners. MetaCard handles the window management, but the stack scripts must handle repositioning and resizing the objects within the window when its size is changed. This type of script is called "geometry management." If you do not want to write a geometry management script, it is best to uncheck the resizeable box in the Stack Properties dialog. Note though that most professional applications do allow resizeable windows, and most users expect them.

MetaCard's cousin Runtime Revolution contains tools that will add geometry management scripts to a stack for you. MetaCard users must write their own. In general, the script resets the loc, rect, height, and/or width of each object relative to other objects in the stack, or relative to the stack's borders.

MetaCard sends a resizeStack system message whenever a user changes the window size. Geometry management is done within a resizeStack handler which is usually placed in the stack script. Note that it is not necessary to lock the screen in a resizeStack handler, because MetaCard does that automatically. If you would like to see an example, any menu group created with MetaCard's Menu Builder tool will have a resizeStack handler that manages the menu bar size. You can look at it by opening the script of the menu group.

The htmlText property

MetaCard fields have an htmlText property which stores the styled text information of the field. MetaCard's htmlText uses tags to mark style information just as a browser does, though it does not support structural tags such as those used for tables or blockquotes. You can see the htmlText of any field by scripting put the htmlText of fld x into fld x. The tags will appear. To set the field back to normal styled display, use set the htmlText of fld x to fld x.

MetaCard also supports embedded images in fields, as well as browser-like text links which, when clicked on, send a message that your script can catch to do something, such as navigate to another location in the stack or open a URL in the user's web browser.

MetaCard internet access

When coupled with MetaCard's native internet support, it is possible to use these capabilities to create a simple MetaCard web browser which might, for example, download to the user's hard drive a set of stacks which are updated and maintained on a web site. This is a good way to provide an online update engine for your customers. A copy of MetaCard on a local machine can also open and run stacks that are stored online. The stack does not need to be downloaded first and saved to disk -- it only needs to exist on the server. One line of MetaTalk in a script will download and open a stack. If you would like to see it in action, try this from the message box:

go stack url "http://www.hyperactivesw.com/mctutorial/tutFiles/TSTS-final.mc"
MetaCard will transparently download the stack into memory and open it on the user's local machine. MetaCard also provides support for sockets and more precise download control, but that is a topic for a more advanced tutorial.

Other features

There are many more features that MetaCard offers which are unavailable in, or differ from HyperCard. Your best bet is to browse through MetaCard's Reference stack to get an idea of the large number of features that are supported.

Experiment. Have fun. The sky's the limit.


HyperActive Software offers professional HyperCard to MetaCard conversions, and has experience with both Macintosh and Windows conversion issues. If you have a HyperCard project that you would like converted, contact us at info@hyperactivesw.com. We can do the entire conversion, or provide consulting services to help you do it yourself. Since this is our business, we cannot answer email questions about conversion issues without a consulting contract. However, if you find errors in this tutorial we would appreciate a note so that we can fix them.



Up to top | Converting Stacks to MetaCard - TOC


Developer ResourcesHome

 

HorizontalBar

Contact us 5226 West Nokomis Pky, Minneapolis MN 55417


 

 

 

 

All contents copyright (C) 1996, HyperActive Software. All rights reserved.
Revised: December 3, 2001
URL: http://www.hyperactivesw.com/mctutorial/tutorialtoc.html