wiki:WxTipsBugsAndQuirks

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
wx.lib.inspection.InspectionTool().Show()

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.

Floatspins Throughout wx History

The floatspin control was first introduced in wxPython 2.8.9, I think, but it was buggy. The first version of wxPython that contained a floatspin with patches that we require was 2.8.11.0. In addition, the 2.8.11.0 version contained backwards-incompatible syntax changes. This means it's easy to support the floatspin in wx ≥ 2.8.11.0, but not if we want to support older versions of wxPython too. The solution for us is to use the wxPython floatspin when the wx version is high enough and fall back on a custom version of the control when it's not.

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.

Spin Controls, SP_ARROW_KEYS, TE_AUTO_URL, SP_WRAP and TE_NOHIDESEL

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: http://trac.wxwidgets.org/ticket/11461

wx.RESIZE_BORDER is the same as wx.THICK_FRAME

wx.RESIZE_BORDER and wx.THICK_FRAME both have values of 64, so it's impossible to set one without setting the other.

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: http://trac.wxwidgets.org/changeset/62685/wxPython/3rdParty/AGW/agw/floatspin.py

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) )

Last modified 7 years ago Last modified on Nov 23, 2011, 12:28:49 PM