Strange behaviour caused by wx.EVT_UPDATE_UI

wxPython Users
#1

Hi.

I have a small application used for creating/editing entries in a small database.

I use a wx.Dialog derived class to create or edit items.
Each items can be of 2 types so I use a boolean for this entry field.

The dialog have a first line with 2 wx.RadioButtons for this type, others controls(text, combobox) and a ‘OK/Cancel’ separated button sizer.

The Ok button is automatically enabled/disabled using an Update_UI event, depending on the content of the controls.

But the problem is that the status of the radiobuttons is inverted when the update_ui event disables the ok button (for example, when I whant to create a new entry, showing the dialog with empty controls).

If the Ok button stays enabled at creation time, all is Ok.

I have created a small simplified project to show the problem.
I consists oof a frame with 3 buttons:

  • the fist one should show the dialog with empty controls (creating a new item) and with the 'Mode 1" radio button selected, but it is shown with the “Mode 2” one selected
  • the second one does the same thing, but with the “Mode 1” radio button selected instead of the “Mode 2” one
  • the third button show the dialog with filled controls(editing an item). Values of the radiobuttons are not inverted in this case as the Ok button is enabled.

If I disable the “Update_UI” event (commenting line 62 of DlgAddEditItem.py), all works fine.

Is this a bug or a ‘normal thing’ ?

Regards
Xav’

DialogTest.zip (4.1 KB)

#2

Try to add event.Skip(True) at the end of OnUpdateUI_BtnOk().

#3

Hi.
Skipping the event has the same effect than not binding it : the radio buttons stays as they should be.
But the event loose it functionality : the Ok button is never disabled as it should be when the other controls of the dialog are empty.

Regards
Xav’

#4

Hi,

Which WxPython version are you using ? Which OS ?
I do tests on Win10x64 WxPython 4.0.6 (x64). Everything seems to work correctly.

Regards,
Nicolas

#5

Hi.
I’m using the last snapshot build of wxPython-4.1.0 with python-3.7.0-x64 on a Windows 10 64bits and with python-3.7.4-32 bits on a Windows 10 32bits.

But you’re right : with wxPython-4.0.6, the small sample I’ve provided in my first post works properly.
The problem seems to comes from wxPython-4.1.0.

Can anyone confirm this ?

Regards
Xav’

#6

It looks like setting a radio button’s value is causing an EVT_RADIOBUTTON event to be sent on MSW and wxPython 4.1, where it wasn’t doing so in 4.0.x, or on 4.1 with at least OSX. (I didn’t check on GTK ports.) It should probably not be doing that. Please check if there is already a report about this on https://trac.wxwidgets.org/ or submit a new ticket if there isn’t one there.

#7

Meaning that it should not be sending the event when it is changed programmatically. Other than a few exceptions, in general events like that should only be sent when the user changes the control.

#8

Hi Robin.
As you said, the doc specifies that the event shouldn’t be sent when changing programatically the value of a radio button.

But the problem here is that the event is not sent if I’m not using the UpdateUi event.
And when I use it, the event is sent to the wrong radio button (you can test this with the small project I’ve attached to the first post).

I’ll have a look on track to see if I find somethign about this.
And I’ll also try to reproduce this behaviour with the C++ version of the framework.

Regards
Xav’

#9

It’s not that the update_ui event is going to the radiobutton. It seems the focus is in the Ok button at the start, probably because it is set as a default button or something. When the button is disabled a navigation event is generated, which is causing the selection to jump to the 2nd radiobutton. If you add this to the end of the dialog’s __init__ so the focus starts out in the first text field, then it will work as expected.

    self.ctrls['txtVal1'].SetFocus()
#10

Hi Robin.
Again, you’re right.
Thank you for the tip.

I’ve tested with a classic C++ application, and I obtained the same result.
I didn’t found any corresponding ticket on trac but I’ll check with Vadim before o pening one.

Regards
Xav’