On Thu, Jan 5, 2017 at 5:26 AM, J. Landman Gay <jac...@hyperactivesw.com> wrote: > > I'm a little surprised that works at all. The "selectedtext" returns a > string, not a position. I'd use "selectedChunk" which would provide a > character location, enabling you to set the cursor at a specific position. > Whilst your definitions of 'selectedText' and 'selectedChunk' are correct, the fact is that 'set the text of the selectedText to "abc"' does replace whatever text you've hilited with whatever text you've specified regardless of whether the text you've hilighted is a long string, a short string or an empty string. The 'normal' result of doing such is that the cursor ends up and the right hand end of the new text, but apparently not so if the new text is numToCodePoint(0xFF001)
I think Richmond should file a Bug report because it does seem he's found an anomaly, or at the very least, if there is a valid reason why this is the case for 0xFF001 (and possibly others) then maybe a Note in the Dictionary describing this situation would be useful. _______________________________________________ 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
