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 Frontier verbs have been designed to follow the style of the UserTalk language and Frontier's built-in verbs. (Player's AppleScript terminology is a compatible subset of object model terminology, but the underlying implementation does not use the object model.)
Q: Why are some verbs in the Player table, and others in the PlayerExtras table?
A: The Player table contains every verb that is common to "PreFab Player" and "Player Runtime". Additional verbs that help compose scripts have been moved to a separate table (PlayerExtras). None of these should be needed to "play" the user interface.
Q: I looked at Player's AppleScript 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". 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 AppleScript version of Player that aren't in the Frontier
version?
A: No. AppleScript is a language, Frontier is an integrated scripting environment -- that is itself
scriptable. In AppleScript, there is no place to put the extensive Player menu,
no object database to store custom verbs, no outline for the result of the PlayerExtras
verbs, and no easy way to compose a verb in the script editor based on the current
balloon contents.
Appendix 2, Verb Parameters