PlayerAppendix 1, Questions & Answers
Q: How is Player different from a keyboard or palette macro program?
A: We believe that Player is the best solution for extending AppleScript and Frontier to tasks that can't be done with direct scripting support. Player is not intended as a direct competitor or complete replacement for keyboard or palette-based macro programs. Additional information can be found in Chapter 2 (above), in the Player brochure, and on our web site, http://www.prefab.com. Some of the web documents may be included on the Player disk.
Q: Player's balloon help doesn't show the name or ID of a dialog item that I really need to control.
Why not?
A: The "Dialog Manager" is the portion of the "Macintosh Toolbox" that programmers can use to easily create standard dialog items. However, many developers are moving away from the Dialog Manager (sometimes for good reasons, sometimes not). In fact, Apple's new Appearance Manager doesn't use the Dialog Manager. Player (along with, to the best of our knowledge, the keyboard macro products) cannot "see" dialog items created with the new Appearance Manager; not by name, not by ID. (Location may work but that's not sufficient for checkboxes and is much more work for the script writer.)
Player 1.1 and later can generally see more items than the keyboard or palette macro products, e.g. controls created with MacApp (such as those in Photoshop 3 and later). No new verbs are required, just use Player's standard verbs. The fine print: includes checkboxes, pop-ups, radio buttons, buttons -- does NOT include text boxes or static text, may not include controls in palettes.
Q: Is the XY location a reliable way to control the user interface? Will the script
still work on a Macintosh that has a different size monitor? What about "movable
modal" dialogs that can come up anywhere on the screen?
A: By default, Player treats XY location values as relative to the frontmost dialog or window, not to the absolute screen location. It is quite reliable (but not very readable). You can easily "hide" the XY locations in suitably named variables so that the main body of the script reads very clearly.
Q: Is Player recordable?
A: No. Making Player recordable is on the "wish list".
Q: Does Player support the object model?
A: No. Player's terminology is a compatible subset of object model terminology, but the underlying implementation does not use the object model. If a future release adds such support, existing scripts can be saved as text, then used in the new version with little or no modification.
Q: Why does AppleScript assign a different text style to Player's verbs, compared to
similar verbs in other applications?
A: Although Player's terminology is essentially compatible with the object model terminology, the actual verbs and objects are implemented differently. Depending on the settings you have selected under "AppleScript Formatting", you may not even notice the subtle differences.
Q: I looked at Player's Frontier verbs. Why are they so different?
A: Our view is that UserTalk (Frontier's native scripting language) and AppleScript have different approaches to language design, so that a literal translation of identical verbs will not "feel" right in the other language.
First, the AppleScript philosophy encourages a minimal set of verbs applied to standard objects, whereas Frontier takes a more traditional view of having separate verbs for distinct functions. For example, Player's UserTalk verbs include clickButton, selectRadio and toggleCheckbox, whereas all three functions are covered by click in AppleScript. The UserTalk verbs are more descriptive, so it is easy to understand a script just by reading it. However, the verbs may be harder to remember since they are so specific. The AppleScript verbs are more general, with the opposite trade-offs.
Second, AppleScript verbs are designed from the ground up with various optional parameters to customize verb behavior. UserTalk allows optional parameters, but they are rarely used. So, Player's UserTalk verbs include clickMouse, doubleClickMouse and nClickMouse, whereas the click verb in AppleScript takes an optional times parameter. (In fact, we designed clickMouse so that it would also accept the optional times parameter, but that is not the "standard" way to do it in UserTalk.)
Finally, AppleScript allows one and only one verb for each Apple event. Frontier provides a layer between the script writer and the underlying Apple event calls, a table of "glue scripts". (A table is like a library that is always available without being explicitly loaded.) For example, Player's glue scripts define a Frontier verb clickDefaultButton, which actually calls the type Apple event with an enter key as the parameter. In AppleScript, the script writer would just directly call type.
Q: Are there any features in the Frontier version of Player that aren't in the AppleScript
version?
A: AppleScript is a language, Frontier is an integrated scripting environment -- that is itself scriptable. The Frontier version of Player includes a custom menu that gives access to the following:
- verbs that outline an application's menus or all the items in a dialog (to the built-in outliner)
- a complete list of verbs from which a selection can be inserted into the frontmost script window with the appropriate parameters
- an enhancement to our balloon help that composes the appropriate Player verb for controlling the user interface item shown in the current balloon
Frontier can host the AppleScript language as well as its native UserTalk language.
Appendix 2, Verb Parameters