On 2017-09-21 18:48, Richard Gaskin via use-livecode wrote:
Indeed it does. At first glance the behavior seems at least
unintuitive. It also appears to prevent the Backspace key from having
any effect. Is it a bug? A feature?
Hmmm...
On further consideration it may make sense, since the selection is
removed by replacing the field contents, and the default selection is
at the beginning of a line.
Indeed!
When you do 'replace x with y in <field>' then the engine:
1) Fetches the text of the field as a string
2) Performs replace x with y on that string
3) Sets the text of the field to the modified string
Whenever a range of text is set in a field, the selection is set to the
beginning of the chunk that was set - so in the case of 'replace' acting
on the whole field, that would be the beginning.
Using the '(replacing | preserving) styles' form works slightly
differently - it iterates through the content of the field, and only
mutates the parts which are to be replaced. So with that form, the
selection index would end up being the beginning of the last occurrence
of x which was replaced with y.
The rule is relatively sensible I think - since if a range of text is
replaced, the only index you can guarantee will be in the same place as
it was before is the beginning of the range which was replaced...
Although it does give a somewhat amusing outcome in this case :)
It would seem the only way to preserve the insertion point would be to
separately trap for all relevant messages (backspaceKey, pasteKey,
dragDrop, keyDown, etc.), where you first query the selectedChunk,
perform the action, then adjust the selectedChunk according to the
length of the operation, and then restore the insertion point at the
adjusted offset.
Yes - I can't think of an alternative approach at the moment which would
be easier. The textChanged message is a bit of a blunt instrument -
mainly because it was the best we could add to the field at the time
without potentially ending up down a whole set of rabbit warrens, or
impacting performance too much.
This seems like so many things in a good scripting language: when you
want to do something ordinary, the provided behaviors make the task
uncommonly easy. But when you want to do something extraordinary, the
task is uncommonly difficult.
Of course one question to ask here is - what are the use cases where you
need to preserve the selection index where the 'set it to the beginning
of the last replaced chunk' isn't appropriate? If script is doing the
mutation, then it can happily save / restore the index itself - so it
would come down to user-interaction cases - finding out about those
would probably help pin down what the field could do to make things
easier.
<slight tangent>
Incidentally whilst the above has the effect of writing bottom to top /
right to left it is only a superficial effect as the order of the chars
ends up being 'the wrong way round' in the internal string. Regardless
of the writing system, humans still (I believe at least...) always
process language in spoken order, which is the same as the order we read
in - the fact some languages are right to left, bottom to top, right to
left to right to left etc. is 'merely' a presentation / visual thing.
For example, let's say you have a right to left language FOO which has
letters A, B, C; compared to a left to right language BAR which has
letters X, Y and Z. Hello in FOO is spoken A-B-C; Hello in BAR is spoken
X-Y-Z. However, as FOO is right to left, Hello is written CBA. If these
languages were mixed in a single piece of text - spoken as A-B-C X-Y-Z -
then in memory the order would be ABC XYZ, but visually it would appear
as either:
i) from the left edge - CBA XYZ
ii) from the right edge - XYZ CBA
Whether it would be (i) or (ii) depends on which is considered to be the
dominant language in that case and context.
</slight tangent>
Warmest Regards,
Mark.
--
Mark Waddingham ~ m...@livecode.com ~ http://www.livecode.com/
LiveCode: Everyone can create apps
_______________________________________________
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
