Mark Wieder wrote:
Richard-
Thursday, March 11, 2010, 10:21:59 PM, you wrote:
I much prefer the way SC handles the pointer tool, splitting messages so
there's a separate suite for when the pointer tool is active:
'Add pointerDown, pointerUp, pointerDoubleUp, etc. for when pointer tool
is active'
<http://quality.runrev.com/qacenter/show_bug.cgi?id=2606>
I read #2606, and it seems to be about catching mouseUp, etc. when you
click on a card in pointer mode. When I've needed to do this I put a
graphic or image at the back of the card and catch mouseUp events
there. Wouldn't that do the trick for you without having to add a new
message to the engine?
Yes, but it won't work out as you might want:
If you're making a drawing app, you'll want to be able to allow the user
to drag a marquee around objects to select them.
If you add another object in back, that object will be selected instead.
If you turn on that object's cantSelect property, you won't get the
marquee selection.
Same with responding to drops in your drawing region, and other mouse
actions in groups.
If you have time on your hands you can write several hundred lines of
code to emulate the pointer tool using the browse tool. But
hand-crafting selection handles and the like is not merely tedious but
very difficult to do well, and seems a substantial waste of programmer
hours given that the pointer tool already provides more than 95% of
what's needed automatically.
If you haven't worked in SuperCard, it may be difficult to fully
appreciate how simple it can be to make a drawing app. Sometimes I miss it.
With Rev's new options for making custom controls (behaviors + the
selectGroupedControls group property - beautiful stuff) the opportunity
for making some mind-blowingly cool custom drawing environments is wide
open, far beyond what we used to do in SC.
But to fully exploit this currently requires a rare level of expertise
with Rev's messaging, a willingness to experiment, and a lot of hard work.
A valuable complement for such work would be to implement tool modes as
a group-specific property:
http://quality.runrev.com/qacenter/show_bug.cgi?id=623
SC has window-specific tool modes which is nice, but with Rev's more
flexible groups it would make more sense, and be far more useful, to
have tool modes specific to the group level. That would allow us to
have some nice single-window UIs with a toolbar, tools panel, and
scrollable drawing region.
You can kinda do that now with careful use of cantSelect, but it's
really a lot of work and not without complication.
And regardless of the scope of tool modes, we still need mouse messages
to be sent to the card when the pointer tool is selected as they are
when the browse tool is selected. If the backward-compatibility issues
for doing so with mouseDown, mouseUp, etc. are too much then
pointerDown, pointerUp, etc. can be considered.
But whatever the means, messages are the lifeblood of interaction. When
we don't get them the blood stops flowing.
--
Richard Gaskin
Fourth World
Rev training and consulting: http://www.fourthworld.com
Webzine for Rev developers: http://www.revjournal.com
revJournal blog: http://revjournal.com/blog.irv
_______________________________________________
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
