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 for. 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 > <email@example.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 firstname.lastname@example.org Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode