Ok I've played with locked, traversalOn, and disabled and the only thing that 
alows me to enable/disable editing of the contents of a field is traversalOn. 
No combination of the other settings allow me to select text (in any manner 
that a user would expect) and yet prevent the editing of the text. 

I can probably check the pEditing property of each stack (which contains 
new|edit|view) in a keyUp handler or something to pass keyUp or no to control 
whether or not a user can edit or no. But it seems like a lot of convolutions 
to go through for something so simple as allowing a user to select and copy 
data from an uneditable field. Think of a web form. You can copy text all the 
live long day and yet not be allowed to edit it. That is what I am shooting 

I agree that if copying is not allowed, or to put it another way, if getting 
the selectedText or hilitedText is not possible, then the UI should not 
indicate that text is selected. So let's kill that first, then consider whether 
or not there ought to be a property that returns the hilited text of a field 
regardless of the status of traversalOn. 

Maybe we can have a new field and button property: editable?

Bob S

> On Feb 24, 2017, at 16:23 , Richard Gaskin via use-livecode 
> <use-livecode@lists.runrev.com> wrote:
> So I agree there's a bug there, but I'd go the other way: if traversalOn is 
> supposed to prevent selections, it should also prevent selections that occur 
> from double-clicking on words.
> -- 
> Richard Gaskin

use-livecode mailing list
Please visit this url to subscribe, unsubscribe and manage your subscription 

Reply via email to