Insertion point problems

[J. Landman Gay]

I don't think traversal is the problem here. When I tested, my button did not have traversalOn set to true (that was the first thing I checked.) The anomaly is that the selectedChunk works fine if the selection contains text, it only fails if the selection is a simple insertion point. 

Both instances should work identically. 

On June 24, 2015 10:27:04 AM CDT, Richard Gaskin <ambassador at fourthworld.com> wrote:
>Yes, the traversalOn property is the key here.
>
>Only one object can have focus at any given time, so when traversing 
>among controls with the keyboard any field selection will be cleared.
>
>But by turning off the traversalOn property for buttons you want to be 
>able to act on text, the focus remains in the field and things work as 
>easily as you'd expect with LiveCode.
>
>-- 
>  Richard Gaskin
>  Fourth World Systems
>  Software Design and Development for the Desktop, Mobile, and the Web
>  ____________________________________________________________________
>  Ambassador at FourthWorld.com                http://www.FourthWorld.com
>
>
>Peter Brigham wrote:
>
>> What I do for this is store the selectedchunk in a customprop or a
>script
>> local on mouseEnter in the button script that will be doing the
>pasting.
>> That way if the mousedown removes the current selection you already
>have
>> the info you need. BTW, if you set the traversalon to false for the
>button,
>> the current selection should be preserved, which will obviate the
>need for
>> this workaround.
>>
>> -- Peter
>>
>> Peter M. Brigham
>> pmbrig at gmail.com
>> http://home.comcast.net/~pmbrig
>>
>>
>> On Tue, Jun 23, 2015 at 7:35 PM, Bob Sneidar <bobsneidar at
>iotecdigital.com>
>> wrote:
>>
>>> On a Mac, I opened two stacks, one with a button, one with a field.
>I
>>> palletized the first stack, then set the insertion point in the
>field in
>>> the second one. Clicking the button in the palletized stack still
>causes
>>> the field on the second stack to lose focus.
>>>
>>> I don’t think there is a way to change this behavior. The workaround
>that
>>> comes to my mind is to have an exitField handler in the field which
>saves
>>> the selection in a property or global variable that the palette
>stack can
>>> access. Alternatively you could have an exitField handler inserted
>as a
>>> front script when the palette opens, so that the selection can be
>saved
>>> somewhere.
>>>
>>> That is how I would go about this.
>>>
>>> Bob S
>
>
>_______________________________________________
>use-livecode mailing list
>use-livecode at lists.runrev.com
>Please visit this url to subscribe, unsubscribe and manage your
>subscription preferences:
>http://lists.runrev.com/mailman/listinfo/use-livecode

-- 
Jacqueline Landman Gay         |     jacque at hyperactivesw.com
HyperActive Software           |     http://www.hyperactivesw.com