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
_______________________________________________ use-revolution mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/use-revolution
