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