I sent this reply once already, several hours ago. It hasn't arrived,
so I thought I'd try again. If you get two copies, I apologize on
behalf of the listserver:
On 8/27/17 1:09 PM, Sannyasin Brahmanathaswami via use-livecode wrote:
> JQ wrote
> CantSelect disallows selection by the edit tool, mostly used in
> development, but doesn't change the message path.
>
> Hmm.. doesn't this comprise a Noobie Gotcha?
>
> cantSelect is not exposed in the PI for any object.
A little background may be helpful:
Scott Raney added the cantSelect property after a long discussion I had
with him about building custom drawing environments.
I had originally suggested to him that we extend the tool property to be
local to groups (similar to the flexibility SuperCard provides with the
tool being local to a window, years later submitted to RunRev as
BZ#623)), and he found that interesting but more work than was available
at that moment in the release cycle.
So instead he came up with the cantSelect property as a workaround to
tide us over in the meantime.
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.
This seemed like a good idea at the time, but in practice is far more
tedious to build with than having the non-browse mode local to the
drawing region group as I'd originally hoped for. Better than having to
completely emulate all pointer tool behaviors from scratch in script
using the browse tool, but still more than I'd wish on a newcomer.
Given the difficulty of attempting to mix tool modes with this property
in LC, in practice this property is seldom used.
The confusion you reported is something I see almost weekly in the
forums with this very unusual property.
I'd suggested replacing that in the Project Browser to govern lockLoc
instead, which is not only far more frequently used but also a much more
common and anticipatable use of a lock icon.
--
Richard Gaskin
Fourth World Systems
_______________________________________________
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
