SuperTalk

This article does not cite any sources. Please help by adding citations to reliable sources. Unsourced material may be challenged and removed. Find sources:  –  ·  ·  · scholar · JSTOR (December 2009) (Learn how and when to remove this template message)

SuperTalk is the scripting language used in SuperCard. SuperTalk is a descendant of HyperTalk.

Extensions to the HyperTalk base language[]

Additional syntax[]

One of the most powerful features SuperCard adds to the HyperTalk language is user properties. Where HyperTalk had a fixed set of properties on its objects, SuperCard scripters can use the define property propName command to add new properties to buttons and fields. These properties can contain arbitrary text (including numbers and object references, which are also represented using text in xTalks), and even dumps of entire files.

SuperTalk provides several variations on HyperTalk's answer and answer file commands, which let one choose several items from a list, choose an icon from all available icons, pick a MIDI instrument to play sound with, or choose a file of a supported image format (including a preview), or disks and folders. Different from HyperTalk's dialogs, SuperTalk answer and ask dialogs do not all resize dynamically to hold more text. However, since SuperCard allows having cards (i.e. "pages") in windows of arbitrary types, one can easily build one's own dialog that is large enough. SuperTalk also has an alert command that displays standard system alert windows and sheets, including standard system icons.

A switch command is available for more readability in complex conditionals, and various types of media can be recorded (e.g. screen grabs of a card, sound and QuickTime movies). There is also a clone command that is equivalent to copying and pasting but leaves the clipboard unchanged, an enumeration command that creates global variables with sequential integer values, and recently MetaCard's familiar repeat for each item x command for iterating through lists was added.

SuperCard also offers exception handling using a try statement with associated throw command.

Differences and incompatibilities[]

SuperTalk came with a source-level debugger well ahead of HyperCard, but the SuperTalk debugger is a modal window and does not let you set breakpoints by just clicking beside a line. A special trace command is used to enter the debugger, where one can then view the currently executing line of code, execute commands, evaluate expressions etc. Because of that, the SuperTalk debugger has to be explicitly turned on instead of being available right away when a script error occurs.

The visual effect command is a little stricter in its syntax, but in exchange supports numerous additional transition effects, including QuickTime transitions and special plug-in modules (stored in data fork resources of type TRAN). A special kind of external command that does not get unloaded and can own a window has been added. Its type is XRTN. It differs noticeably from the XCMD protocol, and also doesn't use the xWindoid protocol later introduced for adding windows to HyperTalk.

SuperTalk also uses a launch command for starting up external applications, different from HyperTalk's open command, which SuperTalk uses for opening its various windows (HyperTalk deviated here by using go to stack "foo" in new window).

Richer object model[]

Of course SuperTalk also exposes SuperCard's expanded object model, making it possible to create sliders, scroll bars, progress indicators and other scales, scriptable paint and draw graphics, and native listbox and first-class menu objects. Multiple windows with several styles (modal panel, non-modal, scrolling, resizable..., floating palettes) are also available and focus and activation scope can be modified under full script control.

Deviations[]

Some parts of SuperCard deviate from the English-like-ness of HyperTalk. This includes the alert command, which tried to emulate the slightly awkward syntax of the answer command a bit too much. Also, it seems that over time, a number of XCMDs were simply rolled into the engine as built-in commands, maintaining the not very memorable handler call syntax. The most obvious case here is the movie function, where movies are kind of "invisibly tacked on" to a window instead of being implemented as real controls like sliders or other elements. There are also some properties that control general application behaviour that are one-to-one translations of the underlying system APIs, e.g. for using "appearance manager" (the theming engine in Mac OS 9).