troubles with masked.combobox

wxPython Dev
1

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

(This breaks the behavior of the masked combobox control, because
it assumes that the above would result in the insertion point being
placed at the beginning of the selection, as with TextCtrls.)

I verified this by editing the simple combobox demo in 2.5.4.1,
by adding an OnChar handler to a combobox that prints the
results of GetInsertionPoint and GetMark before calling evt.Skip(),
and I can work work around this by overriding .GetInsertionPoint(),
using .GetMark() instead and returning the 1st coordinate of the
tuple, but I'd rather not have to, as a) I still think it's a bug,
and b) not all implementations have .GetMark(), and so I'd be
forced to rely on my OTHER hack to provide this function if not
implemented...

Is there anything I can do about this???

Regards,
/Will Sadkin
author, lib.masked

PS: Thanks for handling the bug recently reported re: destroy
on masked controls, Robin!

2

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.

···

--
Robin Dunn
Software Craftsman
http://wxPython.org Java give you jitters? Relax with wxPython!

3

Robin Dunn wrote:

Will Sadkin wrote:

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.

This is also how wxGTK works:

>>> tc.SetInsertionPoint(1)
>>> tc.GetInsertionPoint()
1
>>> tc.SetSelection(1,5)
>>> tc.GetInsertionPoint()
5

But on wxMac the begining of the selection is returned for textctrl and combobox always returns zero because the method hasn't been implemented yet. I've asked on wx-dev what is the RightThing to do.

···

--
Robin Dunn
Software Craftsman
http://wxPython.org Java give you jitters? Relax with wxPython!