cantSelect

[Richard Gaskin]

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