... which instead of an input of 123 resulted in 321.

This Edit::SetText() has a side-effect that it sets a new Selection(0,0)
effectively invalidating the previous selection. We reach
RefEdit::SetRefString() also through notification of edit events that
already handled the key input in Edit::ImplInsertText() and adapted the
selection, the dialog then attempts to update all sort of argument
fields, including the one that was just edited. Setting the identical
text again confuses the selection and positions the cursor at the
beginning of the string instead of the end when typing. Additionally all
kind of invalidations and recalculations happen that were just correct..

This somehow worked before (what change?), maybe just by accident,
Edit::SetText() always set that new selection. However, calculating all
the rat tail for an identical text is unnecessary and hopefully nothing
relies on it. If something did, we'd need to remember and set the
original selection here after setting the text, or adapt the believer..

Change-Id: Ibe086f3620db921dc852280e73789218d81f5c39