Richard:
Hmmm, this could be really useful
a whole responsive palette of control on the side of a card, (instead of a
separate palette stack) while continuing to dev in the main region. useful for
dev.
In fact doesn't this solve a core UX, that is not "ancient"by any means?:
A drawing region with controls on the side/bottom. and all you have to do is
turn on the pointer. (having preset all the other controls to
cantSelect/AlwaysBrowseMode.)
I actually have a use case for this right in front of me if it works on Mobile.
BR
On 8/27/17, 1:29 PM, "use-livecode on behalf of Richard Gaskin via
use-livecode" <use-livecode-boun...@lists.runrev.com on behalf of
use-livecode@lists.runrev.com> wrote:
In addition to what Jacque noted there's something more that can be very
important in some contexts:
It doesn't just prevent the object from being acted on by the pointer
tool, but moreover always acts as though its own object-local tool mode
is the browse tool, regardless of whatever other tool is in effect.
"CantSelect" is a very Raney name; "AlwaysBrowseMode" would be more
descriptive.
This means your object will get all the messages you'd expect to get
with the browse tool regardless of the current global tool property, but
only for that one object.
This can be useful for contexts in which you want to allow the user to
use the pointer tool, but also provide a toolbar or other controls they
can use to select shapes, colors, etc.
_______________________________________________
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
