How to to type bottom to up and right to left in a field

Mark Waddingham mark at
Thu Sep 21 13:48:24 EDT 2017

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.


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 

<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 Waddingham ~ mark at ~
LiveCode: Everyone can create apps

More information about the Use-livecode mailing list