Conversion from HyperCard, SuperCard, or OMOWhether it's to achieve cross-platform portability, to improve the performance or capabilities of a product, or to switch to a tool supported by a stable, long-term oriented company, it's becoming increasingly common for applications developed in HyperCard, SuperCard, Oracle Media Object (OMO), WinPlus/ObjectPlus, or HyperSense to be ported to MetaCard. Though some work will be required to convert most applications to MetaCard, in most cases it will only be a small fraction of the time and effort required to redevelop the product from scratch using some other language.
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 HyperCardMetaCard can import HyperCard stacks directly from their native file format on all platforms. All objects and object properties (including scripts), bitmaps, icons, cursors, and sounds are converted. PICT images, colors (AddColor), and other information stored in the resource fork are not converted.
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 OMOConversion from SuperCard and OMO requires the use of a converter. These converts have two components. The exporter component runs in the source environment and exports a text file representation of the stack/project. The importer component runs in MetaCard and builds a MetaCard stack based on the information in the text file. The converters are available on this site as sctomc.sit and omotomc.sit.
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 HyperSenseNo pre-built automated conversion is possible from these tools to MetaCard. For small projects, reconstructing the project using the MetaCard development environment is the most efficient route. It may be possible to use copy/paste to move scripts from the source tool to MetaCard, greatly speeding development of the new application.
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 ConversionThe core of the various xTalk dialects are very compatible, and in general MetaCard is more compatible with any of the other tools than they are with each other (considerable effort has been made to improve compatibility). For example, MetaCard supports both the dynamic message path used in HyperCard and OMO, and the static path used in SuperCard. It supports shared text and button hilites like HyperCard, and graphic objects like SuperCard. In addition, many of the commands and functions that are handled in HyperCard and SuperCard (like flushEvents and getResources) are built into the MetaTalk language.
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.
|Product Info | Overview . Features . Pricing . HC/SC/OMO . RG . K-12|