Scripting approach for a splittable window?

[Richard Gaskin]

Joe Lewis Wilkins wrote:

> I guess not too many Revers are heavily into drawing applications.
> 
> Several months ago I started to do pretty much what you're describing,  
> but got discouraged because I knew I had already done "something"  
> similar to it years ago using FutureBasic, and it wasn't nearly as  
> difficult. More direct.

Coming from many years with SuperCard, this is one of the very few areas 
where I've been disappointed with the Rev experience.

The design philosophy with SC was that all tools are available to the 
scripter for use in their apps, and because the pointer tool is used in 
a very different context from the browse tool is has its own set of 
messages (pointerDown, pointerUp, pointerDoubleUp, etc.).

For many years Rev the philosophy seemed to be that the pointer tool, 
while available to developers to use if they can, exists primarily for 
the benefit of layout tasks within the IDE.

There is some merit to this approach, but also some compromises.

The upside is that the arrow tool was really only useful for working 
with native primitives (buttons, fields, etc.), and modern drawing apps 
like MacDraft need more complex objects anyway so historically the 
thinking was that if you need complex objects use the browse tool and 
emulate all of the pointer tool behaviors.

The downside was that it sounds simple enough, but ask anyone who's done 
it just how simple it is to maintain each object in a nested group which 
contains a group of control handles for indicating selection and 
resizing.  It's a lot of work to set up, adds a tremendous amount of 
complexity to your code, and noticeable lags when you work with it 
relative to the snappy performance and ease of implementation with the 
pointer tool, where selection handles just naturally come along for the 
ride.

Rev took a giant leap forward toward supporting the crafting of modern 
drawing environments with v3.5, which now allows groups to have their 
own selectGroupedControls property settable independently of the global 
property of the same name.   In conjunction with 3.5's new 
group-specific messages, and with Behaviors so you can manage any number 
of custom control instances from a single script, you can now craft 
custom controls which work gracefully with the pointer tool in many 
circumstances.

But there are still a few weaknesses:

Line and polygon objects still cannot be interactively resized to be 
perfectly horizontal or vertical.  It's not merely that it doesn't 
support the conventional convenience of doing this automatically when 
dragging with the Shift key, it simply can't be done at all without the 
new editMode property, which carries subtle but important implications 
that make it suboptimal for end-user drawing environments, as Ken notes 
here:
<http://quality.runrev.com/qacenter/show_bug.cgi?id=7706>

Also, some mouse messages are only sent to controls when the pointer 
tool is active, while they're also sent to the card when the browse tool 
is active, such as dragEnter, making it difficult for a drawing pane to 
respond to some events.

We might consider using a graphic object at the back of the drawing pane 
to catch such messages, and with the cantSelect property settable so 
that the object will always behave as though the browse tool is active 
that will indeed get the message.  But the downside is that it then 
prevents drag-selecting around objects with a marquee.

Another challenge is not being able to interactively create controls 
within groups.  If your app provides a way for a user to add a shape, 
you must use drag-and-drop to do so (trapping mouseMove to compensate 
for the absence of dragEnter, as noted above), because there's currently 
no tool mode specific to groups.
<http://quality.runrev.com/qacenter/show_bug.cgi?id=623>

Alternatively you could let the user create the control above the group 
and copy it into the group on newGraphic, newButton, etc., but if the 
new control overlaps the scrollbar it just looks wonky.

Another benefit to having tool modes being specific to groups is that 
you could then easily have a single window with multiple panes in which 
some of those panes are tools and others are the drawing region.  This 
is as common in modern apps as using palettes for tools has been 
historically, and in Rev can only be done if you set the 
selectGroupedControls of every object outside of your drawing pane to 
true (and also suspend the IDE when you're working on such things, as 
most mouse messages are trapped by the IDE when the pointer tool is active).

Scaling the drawing region can be done in script, but is very cumbersome 
and error-prone.  A strong nice-to-have would be the ability to scale 
the display of stacks and groups:
<http://quality.runrev.com/qacenter/show_bug.cgi?id=6589>


All that said, Rev 3.5's new behaviors, and group-specific messages and 
properties, took the engine a giant leap forward for making drawing apps.

With a few more enhancements to messaging there's almost no end to what 
can be crafted in Rev, but at least we no longer need to emulate the 
pointer tool with the browse tool for every such app; there are at least 
useful workarounds which may be cumbersome but far less effort than 
emulating pointer tool behaviors.

Useful visits to the Dictionary for folks making drawing apps:

- behavior object property
- boundingRect group property
- cantSelect object property
- clone command
- copy <obj> to <dest> command
- editmode graphic property
- newTool message
- selectGroupedControls group and global property
- tool global property


--
  Richard Gaskin
  Fourth World
  Revolution training and consulting: http://www.fourthworld.com
  Webzine for Rev developers: http://www.revjournal.com