Difference between Run tool and Edit tool
ambassador at fourthworld.com
Sat Oct 23 14:40:42 EDT 2004
Marty Billingsley wrote:
> If the run tool is for running a stack and the edit tool is for editing
> it, why do scripts even run in edit mode? mouseEnter, mouseLeave,
> openCard, closeCard, etc. all are executed even when the edit tool is the
> one selected. But mouseDown and mouseUp aren't.
The problem is less about the actual behavior than the nomenclature used
for those tooltips. I would suggest changing them to simply "Browse
Tool" and "Pointer Tool" to minimize confusion. While the current
tooltips include those words, they do so parenthetically and the first
word is, as you noted, "Run" and "Edit" respectively.
The problem is that the terms "Run" and "Edit" are misleading, because
in an xTalk like Revolution you're always running. One of the
conceptual hurdles newcomers experience if they come from another
language is that in other systems there is very definitely a clear
distinction between "run" and "edit" modes. For that reason, rather
than use nomenclature that suggests that Rev is something other than
what it is, it would seem more helpful to draw attention to how it
Whether in the development environment or your application, at the heart
of things is the engine, which is always running. Messages are sent in
response to user interactions, and the nature of those interactions are
governed by a global property called the "tool".
The most common runtime interactions involve clicking things and editing
text, and those behaviors come with the Browse Tool.
The engine also support a wide range of interactions common in drawing
and layout programs, such as selecting objects and resizing them with
their bounding handles. Those layout behaviors come with the Pointer Tool.
For creating objects there are also Button, Field, Image, and Graphic
tools. See the "choose" command for a list of available tools.
Unless noted in the docs, most tools send the same messages regardless
of which one is currently in use. This allows you to write an app that
responds to a click on a button in the "normal" way with the Browse
Tool, or to select it and update an inspector palette with the Pointer Tool.
One of the key challenges to building a development environment with an
engine this flexible is determining when to pass messages to the object
and when to keep them for use by the IDE without passing them. It's a
deeply Zen challenge for which I've found no solution that optimally
suits all needs. But at least being able to look up messages in the
Dictionary to see how they behave (assuming, of course, the
documentation notes those few cases where the IDE alters the engine's
native behavior) makes working with them not all that hard, and perhaps
ultimately the freedom and flexibility is quite liberating.
For more on this koan of passing or not passing messages in the
development environment, see this post from last month:
Fourth World Media Corporation
Rev tools and more: http://www.fourthworld.com/rev
More information about the Use-livecode