troubles with masked.combobox

Robin Dunn wrote:

Will Sadkin wrote:

Hi Robin et al,

I just did some spot checking of my controls in the new 2.5.4.1
release, and the masked.ComboBox is now broken, due to what appears
to be a recent change (dare I say bug?) in the underlying
implementation of how the insertion point and selection are handled
on comboboxes (at least under Windows).

It used to be the case that for both TextCtrls and ComboBoxes,
you could (and had to) set the insertion point and text
selection independently.

However, for ComboBoxes, it now appears that the insertion point is
always returned as the end of the current selection, ie.
(paraphrasing:)

cb.SetInsertionPoint(1)
cb.SetSelection(1,5)
cb.GetInsertionPoint()

5

Actually, I think that the bug might be in wxTextCtrl and that
wxComboBox is doing it right. If I do something like the above with a
textctrl then, yes I get a value of 1 from GetInsertionPoint, but if I
look at the control the caret is flashing at position 5.

It actually depends on how you make the selection; if you drag
from left-to-right, the cursor blinks on the right, but if you
drag from right-to-left, the reverse happens. This does not, however,
appear to affect the insertion point returned. Both of these
observances are also true for ComboBox, but the insertion point
returned is always at the end, rather than always at the beginning.

I think the TextCtrl returns the insertion point at the
beginning, because, as you type, whatever is selected is replaced,
and your "effective" position ends up as though the selected
text was deleted, the cursor moved to where the selection started.
Then your character is inserted; the resulting insertion position
therefore "moves backward" on input.

Unlike the default TextCtrl, the *masked* controls always
*replace* characters selected, (possibly with the "fillChar" or
the masked out characters, as appropriate), and always work left-to-right,
even when doing "right-insertion" (probably because of the underlying
implementation limitations I ran into early on, but also because of
the above analysis.) At this point, the code around this logic is
so complicated that I REALLY don't want to have to completely rewrite
it all...

/Will

ยทยทยท

_____________________________________________________________________

William Sadkin
author, lib.masked