wxTextCtrl::SetValue() doesn't set insertion point to 0

[raf]

winnt, wx-2.8.8.1
macosx-10.4.11, wx-2.8.8.1
ubuntu-8.x, wx-2.8.7.1 [not the latest]

Calling TextCtrl.SetValue() or ChangeValue() has an
undesirable side effect and it varies across platforms.

On Windows, it sets the insertion point to the start of
the text in the control.

on MacOSX, it sets the insertion point to the end of the
text in the control.

On Linux, this side effect is not present.

I've seen code in wx demos (i think) and on the net (definitely)
where people call SetInsertionPointEnd() immediately after
calling SetValue().

I assume that they do this because they are familiar with
the Windows behaviour of SetValue().

However this is not a good idea. If the insertion point
had been in the middle of the text before the call to
SetValue(), then blindly calling SetInsertionPointEnd()
would move it when the intention was probably to leave it
alone.

The attached program demonstrates all this and it contains
detailed traces of what happens when run on different
platforms.

Anyway, the code there tries to eliminate the side effect
on all platforms.

While doing this, I noticed that GetInsertionPoint() doesn't
work on Linux in an EVT_TEXT handler. it returns a value
that is 1 less than it should be. In a EVT_KEY_DOWN handler
on the other hand, it does return the correct value.

Also, calling SetInsertionPoint() in the EVT_TEXT
handler has no effect on Linux unless called using
CallAfter(). Of course, if using CallAfter(), the insertion
point would be set to the wrong value if the insertion
point had been saved in the EVT_TEXT handler.

Anyway, the behaviour of GetInsertionPoint() in an EVT_TEXT
handler on Linux looks very much like a bug to me.

The side effect that SetValue/ChangeValue have of altering the
insertion point in different ways on MacOSX and Windows
is undesirable in that it seems that everyone that uses SetValue
has seen fit to try to correct for it and not done it
properly. I would like to see the side effect eliminated
completely in wx. The insertion point should only be
affected by a call to SetValue() if the length of the value
changes so as to remove that character position.

[vadz]

The Windows behaviour is the "correct" one, i.e. one which the other ports should follow. And in the trunk wxGTK does do it like this (and there is a unit test to prove it).

So the only real problem is that wxMac doesn't do it yet, although maybe it was fixed by the change in wxTextEntryBase::DoSetValue() too? It would be nice if someone could test this under Mac with the latest svn. I'm a bit lost in its code to be able to deduce it from just reading it (but it doesn't look good as it doesn't seem to reuse the common code at all).