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
_______________________________________________
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution
