Difference between Run tool and Edit tool

[Richard Gaskin]

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 
actually works:

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:
<http://lists.runrev.com/pipermail/use-revolution/2004-September/043466.html>

--
  Richard Gaskin
  Fourth World Media Corporation
  __________________________________________________
  Rev tools and more: http://www.fourthworld.com/rev