Changes between Initial Version and Version 1 of WxTipsBugsAndQuirks


Ignore:
Timestamp:
Nov 5, 2010, 2:31:38 PM (10 years ago)
Author:
flip
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • WxTipsBugsAndQuirks

    v1 v1  
     1= Miscellaneous wx-Related Tips, Bugs and Quirks =
     2
     3== Printing The Version ==
     4To print your wx version, execute this at the command line:
     5{{{
     6python -c "import wx; print wx.version()"
     7}}}
     8
     9== The Inspector ==
     10
     11The Widget Inspection Tool is an extremely useful tool for debugging. To turn it on, add this to your Python code:
     12
     13{{{
     14#!python
     15import wx.lib.inspection
     16wx.lib.inspection.InspectionTool().Show()
     17}}}
     18
     19Sometimes when I place this code inline, I get a strange runtime error on the first line of code that references wx:
     20
     21{{{
     22UnboundLocalError: local variable 'wx' referenced before assignment
     23}}}
     24
     25I 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.
     26
     27
     28== Spin Controls, Enter, and OS X ==
     29Under OS X, a spin control can't capture the EVT_TEXT_ENTER event. The problem is that on the Mac, there's
     30no native spin control, so wx fakes one with a text control and a spin button placed side by side. When the
     31text control is created, it is not passed the wx.TE_PROCESS_ENTER flag which is required to make it capture
     32enter. You can see this for yourself with the following code:
     33
     34{{{
     35for kid in your_spin_control.GetChildren()
     36    if isinstance(kid, wx._controls.TextCtrl):
     37        print (kid.GetWindowStyle() & wx.TE_PROCESS_ENTER)
     38}}}
     39
     40== Spin Controls and OS X Size Issues ==
     41For 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.
     42
     43== Spin Controls, SP_ARROW_KEYS, TE_AUTO_URL, SP_WRAP and TE_NOHIDESEL ==
     44
     45When 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.
     46
     47I filed this ticket against wxWidgets to track this: http://trac.wxwidgets.org/ticket/11461
     48
     49== Floatspin Controls and Enter ==
     50
     51The 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
     52
     53This is already integrated in our custom version of the floatspin control.
     54
     55== wxWidgets under KDE ==
     56
     57Under 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.
     58
     59
     60== Floatspin Controls, Size and MinSize ==
     61
     62Floatspin controls require some care to size properly. Here's some things to
     63be aware of.
     64
     65 * By default, most (all?) newly-created controls in wxGlade start with a
     66   proportion of 0. Floatspins, however, start with a proportion of 1. If you
     67   don't change that to 0, they'll expand to fill their sizer even if you have
     68   wxEXPAND turned off.
     69 
     70 Since this means floatspins work differently than most controls, I might
     71 report it as a bug.
     72 
     73 * The size passed to a wx control in the constructor also becomes the
     74   control's minimum size. This is strange to me, but apparently it's by 
     75   design, so there must be a good reason for it.
     76 
     77 Good reason or no, this affects us directly. The code that wxGlade
     78 generates never sets the size in the constructor even if you specify a size
     79 for the control in design mode. (It creates the control and sets the size
     80 later, if necessary.)  The floatspin control, therefore, uses the default
     81 width of 95 which is hardcoded in the constructor. This combined with
     82 wxWidget's min size quirk means that '''floatspins created by wxGlade always
     83 start with a min width of 95'''.
     84 
     85 Therefore, if you want your floatspins to be able to be smaller than 95
     86 pixels wide, you need to call SetMinSize() before calling SetSize(). e.g.
     87 
     88 {{{
     89#!python
     90self.spinThingy.SetMinSize( (60, -1) )
     91self.spinThingy.SetSize( (60, -1) )
     92 }}}
     93 
     94