Bad Crash on Attempt to Group Radio Buttons
Sannyasin Brahmanathaswami
brahma at hindu.org
Mon Aug 28 00:37:01 EDT 2017
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-bounces at lists.runrev.com on behalf of use-livecode at 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.
More information about the use-livecode
mailing list