I had an owner draw combobox in 2.9.1.1, and I used the GetSelection() method to get the currently selected item of it. In 2.9.4.0, though, GetSelection() gives me back a tuple, which is (I guess) the selected text in the combobox’s edit control (owner draw comboboxes don’t have an edit control).
So I’m wondering what the new correct method is for getting the currently selected item from an owner drawn combobox.
I’ve modified the owner draw combobox example from the wxpython demo slightly to show the problem. Look for the “ADDED TO DEMO” comments to see what I’ve added. This is in the 2.9.4.0 demo.
I've made a fix to better disambiguate the [G|S]etSelection methods so it will use the ones inherited from wx.ItemContainer instead of the ones from wx.TextEntry. This will be in the next 2.9.5 preview build, keep an eye on wxPython-dev for an announcement of when that is done. (Probably not until the weekend, at least.)
···
On 1/15/13 8:12 AM, dhyams wrote:
I had an owner draw combobox in 2.9.1.1, and I used the GetSelection()
method to get the currently selected item of it. In 2.9.4.0, though,
GetSelection() gives me back a tuple, which is (I guess) the selected
text in the combobox's edit control (owner draw comboboxes don't have an
edit control).
So I'm wondering what the new correct method is for getting the
currently selected item from an owner drawn combobox.
I've modified the owner draw combobox example from the wxpython demo
slightly to show the problem. Look for the "ADDED TO DEMO" comments to
see what I've added. This is in the 2.9.4.0 demo.
In Classic we try to avoid it by renaming methods. In Phoenix we can leave them alone in most cases because it has very good support for overloading and resolving the overloads at the time the method is called. In this case however the problem was due to multiple inheritance and the same method name being in two branches of the class ancestry, and with the way Python's MRO works it was finding the wrong implementation of [S|G]etSelection first.
···
On 1/16/13 2:56 PM, dhyams wrote:
No one else sees similar behavior? What is wxPython supposed to do
if there are two implementations of the same member function in a class?
Thanks so much Robin! Is the fix in a publically available svn
somewhere? I could snag it and test it out.
···
On Wed, Jan 16, 2013 at 7:57 PM, Robin Dunn <robin@alldunn.com> wrote:
On 1/16/13 2:56 PM, dhyams wrote:
No one else sees similar behavior? What is wxPython supposed to do
if there are two implementations of the same member function in a class?
In Classic we try to avoid it by renaming methods. In Phoenix we can leave
them alone in most cases because it has very good support for overloading
and resolving the overloads at the time the method is called. In this case
however the problem was due to multiple inheritance and the same method name
being in two branches of the class ancestry, and with the way Python's MRO
works it was finding the wrong implementation of [S|G]etSelection first.
Again, thanks much…I should have looked there first; I just figured that it was hidden away in a branch somewhere. Sorry about that.
One last little Q if I may…the page here Phoenix/README.rst at master · wxWidgets/Phoenix · GitHub says that there is a windows SWIG binary available, but the link that it points to is dead. Does that binary exist somewhere that it can be nabbed?
···
On Wednesday, January 16, 2013 9:38:05 PM UTC-5, Robin Dunn wrote:
On 1/16/13 5:57 PM, Daniel Hyams wrote:
Thanks so much Robin! Is the fix in a publically available svn
Again, thanks much...I should have looked there first; I just figured
that it was hidden away in a branch somewhere. Sorry about that.
One last little Q if I may...the page
here Phoenix/README.rst at master · wxWidgets/Phoenix · GitHub says that there is a windows
SWIG binary available, but the link that it points to is dead. Does
that binary exist somewhere that it can be nabbed?
Sometimes they can get a bit out of sync, but most of the time using wxWidgets trunk with wxPython trunk will work. If there are build problems then you can try moving your wxWidgets tree back to the same day/time of the latest wxPython commit.
···
On 1/17/13 7:52 AM, dhyams wrote:
Thanks yet again, and I do apologize for yet another follow-up question.
I got wxPython from svn, but what wxWidgets do I pair it up with? I
looked through the tags for wxWidgets, but did not see anything appropriate.
What is wxPython supposed to do if there are two implementations of the same member function in a class?
What is wxPython supposed to do