Version 1 (modified by flip, 10 years ago) (diff)


Miscellaneous wx-Related Tips, Bugs and Quirks

Printing The Version

To print your wx version, execute this at the command line:

python -c "import wx; print wx.version()"

The Inspector

The Widget Inspection Tool is an extremely useful tool for debugging. To turn it on, add this to your Python code:

import wx.lib.inspection

Sometimes when I place this code inline, I get a strange runtime error on the first line of code that references wx:

UnboundLocalError: local variable 'wx' referenced before assignment

I think wx is doing something funny under the covers. For me, moving the import wx.lib.inspection statement to the top of the file just after import wx is sufficient to solve the problem.

Spin Controls, Enter, and OS X

Under OS X, a spin control can't capture the EVT_TEXT_ENTER event. The problem is that on the Mac, there's no native spin control, so wx fakes one with a text control and a spin button placed side by side. When the text control is created, it is not passed the wx.TE_PROCESS_ENTER flag which is required to make it capture enter. You can see this for yourself with the following code:

for kid in your_spin_control.GetChildren()
    if isinstance(kid, wx._controls.TextCtrl):
        print (kid.GetWindowStyle() & wx.TE_PROCESS_ENTER)

Spin Controls and OS X Size Issues

For some reason (probably related to the lack of a native spin control under OS X), one must call SetMinSize() on a spin control before calling SetSize() for the latter to have any effect. This is not the case under Windows or Linux.


When using a spin control in wxWidgets, it's impossible to set SP_ARROW_KEYS independently of TE_AUTO_URL. Ditto for SP_WRAP and TE_NOHIDESEL. The problem is that the former are both 4096 (0x1000) while the latter are both 8192 (0x2000). When a textbox and spin button are combined into one control, the constants overlap.

I filed this ticket against wxWidgets to track this:

Floatspin Controls and Enter

The floatspin control in the wxPython library doesn't trap enter. I submitted a patch for this problem and it was accepted as r62685:

This is already integrated in our custom version of the floatspin control.

wxWidgets under KDE

Under KDE, wxWidgets uses GTK to draw its widgets, so there's no KDE-specific version of wx. AFAICT that's mostly because KDE uses QT as its windowing toolkit, and QT is a competitor to wxWidgets. As a result, there may be licensing problems if wx was to wrap QT's widget set. Thus there is not and probably never will be a KDE version of wx.

Floatspin Controls, Size and MinSize

Floatspin controls require some care to size properly. Here's some things to be aware of.

  • By default, most (all?) newly-created controls in wxGlade start with a proportion of 0. Floatspins, however, start with a proportion of 1. If you don't change that to 0, they'll expand to fill their sizer even if you have wxEXPAND turned off.

Since this means floatspins work differently than most controls, I might report it as a bug.

  • The size passed to a wx control in the constructor also becomes the control's minimum size. This is strange to me, but apparently it's by design, so there must be a good reason for it.

Good reason or no, this affects us directly. The code that wxGlade generates never sets the size in the constructor even if you specify a size for the control in design mode. (It creates the control and sets the size later, if necessary.) The floatspin control, therefore, uses the default width of 95 which is hardcoded in the constructor. This combined with wxWidget's min size quirk means that floatspins created by wxGlade always start with a min width of 95.

Therefore, if you want your floatspins to be able to be smaller than 95 pixels wide, you need to call SetMinSize() before calling SetSize(). e.g.

self.spinThingy.SetMinSize( (60, -1) )
self.spinThingy.SetSize( (60, -1) )