Conversion from HyperCard, SuperCard, or OMO

After conversion, you'll instantly benefit from the average 5 times better script execution performance MetaCard has over HyperCard and SuperCard (see the Benchmarks page for details), and the 32K script and field contents length limits will no longer constrain your development (MetaCard scripts can be 64K per object, and there is no limit on the amount of text you can put into fields).

Conversion from HyperCard

On Macs, MetaCard can import directly from HyperCard stacks. On Windows and UNIX systems, the stacks can be imported in raw binary, BinHex, and MacBinary formats, the latter two preserving resource-fork information including icons, cursors, and sounds. For best results, compact a stack before importing it.

After importing, conversion usually consists of addressing script-language compatibility issues, changing the size of objects and fonts to improve the look of the UI, and editing or replacing the bitmap images used in the stacks (many HyperCard stacks have white areas painted on them which are invisible with HyperCard's default white background, but become very obvious when viewed on MetaCard's default gray background).

MetaCard supports most HyperCard XCMDs and XFCNs, but these are not copied automatically from the resource fork of HyperCard stacks when they are imported. Simce XCMDs are not portable across platforms, you should first determine whether or not MetaCard has a feature built-in that is performed by an XCMD in the HyperCard stack. If an XCMD or XFCN is really required, you can move it into the resource fork of the MetaCard stack after you save it.

An excellent tutorial that shows how to convert a HyperCard application to MetaCard is available at http://www.hyperactivesw.com/mctutorial/.

Conversion from SuperCard and OMO

Due to relatively poor performance of SuperCard and OMO, the exporter generally runs quite slowly and can take hours to export large stacks. We recommend breaking up large projects into small pieces (1MB or less each) prior to conversion for best results. After conversion, script compatibility and font and object size issues will need to be addressed, just as with HyperCard.

An enhanced version of the SuperCard to MetaCard converter that converts bitmap objects is available on the Cross Worlds WWW site.

Conversion from ObjectPlus/WinPlus and HyperSense

For larger projects, building an automated conversion tool may be worth considering. Since a new converter could be based on the existing SC or OMO converter, it may not be very difficult to build such a tool.

Script Conversion

There are a few key areas where compatibility problems frequently arise, however. The most common of these is in menu-handling scripts. Each of the xTalk-based products handle menus differently, partly because of the demands of the various development platforms (Windows and UNIX have no system menu bar like MacOS does), but also because menu support was the most recently added or enhanced in these products. As a general rule, figure that every script statement that refers to menus will need to be changed. Menu support in MetaCard is comparable to that available in the other tools, however, so extensive redesign of menu management routines will not be required in most cases.

Secondly, since the MetaCard development environment is very different from that used in any of the other tools, scripts that alter the development environment (by accessing the Mac menu bar or palettes or debugging features) won't run correctly in MetaCard. MetaCard's support of the HyperTalk doMenu command is rudimentary because of this limitation. Instead, MetaTalk has equivalent functions built into the scripting language (e.g., cut/copy/paste/create card/etc.), and these commands should be used instead of doMenu.

There are many instances where the other xTalk languages are more lenient than MetaTalk's. For example, the use of the word "the" in function and property names is more strictly enforced in MetaCard. Another potential trouble spot is that HyperCard allows predefined terms, such as function and property names, to be used as variable names, whereas MetaCard generally does not.

Since MetaCard has many more built-in commands, functions, and properties than HyperCard, it is much less tolerant of leaving quotes off of literals than HyperCard. The SuperCard-compatible feature "explicitVariables" allows you to set MetaCard's script compiler to flag unquoted literals as errors.

MetaCard is slightly more lenient than HyperCard when addressing objects. When a button or field is specified in MetaCard, both cards and backgrounds are searched, as a opposed to HyperCard where buttons are searched for on cards, and fields on backgrounds. You can override this behavior by using the word "card" or "background" in the object specification.

MetaCard supports custom (user-defined) properties, compatible with those used in SuperCard and Oracle Media Objects. There is no need to predefine property names with the "define" command like you must in OMO, though the "define" command is supported in MetaCard for compatibility purposes. MetaCard also supports getprop and setprop "triggers" which are called when custom properties are set or retrieved, a important feature missing in OMO and SuperCard.

MetaCard Corporation encourages users to report any incompatibilities they find to help achieve the goal of making MetaCard capable of importing and executing a greater percentage of HyperCard stacks unmodified in the future. When in doubt, consult the MetaTalk Reference stack to verify whether a feature is supported or not.

[ MacDevWebRing Home ]
[ Previous 5 Sites | Previous | Next | Next 5 Sites ]
[ Random Site | List All Sites ]

Back | Random | List | Next

This Mac Programmer's Array site owned by MetaCard Corporation. [ Previous 5 Sites | Skip Previous | Previous | Next | Skip Next | Next 5 Sites | Random Site | List Sites ]

This Ultimate HyperCard Webring site owned by MetaCard Corporation. [ Previous | Next | Join | Random Site | List Sites ]