wx.gizmos LEDNumberCtrl not following wx.NO_BORDER

Hello,

I'm relatively new to wxPython (and wx in general). I'm working on a
small project, and have been baffled by this... it seems that the
wx.gizmos.LEDNumberCtrl doesn't recognize/follow a style which
includes wx.NO_BORDER. It draws a border regardless. I'm using the
SuSE python-wxGTK package, 2.8.10.1.

I've investigated the code, but the SWIG wrapper was enough to confuse
my minimal knowledge of C++. I know that there are some maintenance
issued surrounding the gizmos stuff, and it seems that the
LEDNumberCtrl module is no longer maintained (as per wxCode).

Any suggestions? Has anyone else out there noticed this issue? At this
point, I'm not 100% sure if it is, in fact, a bug (or perhaps some
weird issue on my system, or old code in the SuSE packages) and if it
is, I don't know if it's present in the original C++ source, or could
be something introduced through the SWIG/Python stuff... So I'm at
least wondering if other people running wxPython can confirm this, and
maybe if someone out there has used wxWidgets directly through C++ and
can confirm if it exists there as well?

Thanks in advance for any help, pointers, ideas, etc.
Jason Antman
Rutgers University

wx.BORDER_NONE and NO_BORDER work fine in the demo app with windows.

Mark

···

On Jun 16, 5:30 am, jantman <ja...@jasonantman.com> wrote:

Hello,

I'm relatively new to wxPython (and wx in general). I'm working on a
small project, and have been baffled by this... it seems that the
wx.gizmos.LEDNumberCtrl doesn't recognize/follow a style which
includes wx.NO_BORDER. It draws a border regardless. I'm using the
SuSE python-wxGTK package, 2.8.10.1.

I've investigated the code, but the SWIG wrapper was enough to confuse
my minimal knowledge of C++. I know that there are some maintenance
issued surrounding the gizmos stuff, and it seems that the
LEDNumberCtrl module is no longer maintained (as per wxCode).

Any suggestions? Has anyone else out there noticed this issue? At this
point, I'm not 100% sure if it is, in fact, a bug (or perhaps some
weird issue on my system, or old code in the SuSE packages) and if it
is, I don't know if it's present in the original C++ source, or could
be something introduced through the SWIG/Python stuff... So I'm at
least wondering if other people running wxPython can confirm this, and
maybe if someone out there has used wxWidgets directly through C++ and
can confirm if it exists there as well?

Thanks in advance for any help, pointers, ideas, etc.
Jason Antman
Rutgers University

Hello,

I'm relatively new to wxPython (and wx in general). I'm working on a
small project, and have been baffled by this... it seems that the
wx.gizmos.LEDNumberCtrl doesn't recognize/follow a style which
includes wx.NO_BORDER. It draws a border regardless. I'm using the
SuSE python-wxGTK package, 2.8.10.1.

I've investigated the code, but the SWIG wrapper was enough to confuse
my minimal knowledge of C++. I know that there are some maintenance
issued surrounding the gizmos stuff, and it seems that the
LEDNumberCtrl module is no longer maintained (as per wxCode).

Any suggestions? Has anyone else out there noticed this issue? At this
point, I'm not 100% sure if it is, in fact, a bug

Yes and no. It is a bug, but probably not the one you are thinking of.

(or perhaps some
weird issue on my system, or old code in the SuSE packages) and if it
is, I don't know if it's present in the original C++ source, or could
be something introduced through the SWIG/Python stuff... So I'm at
least wondering if other people running wxPython can confirm this, and
maybe if someone out there has used wxWidgets directly through C++ and
can confirm if it exists there as well?

The widget is passing the style flag on to the base class, so it will deal with the standard borders as expected. The problem is actually in the LED's OnPaint method. See:

http://trac.wxwidgets.org/browser/wxWidgets/branches/WX_2_8_BRANCH/contrib/src/gizmos/ledctrl.cpp#L166

It draws the background by drawing a rectangle that fills the control, but it doesn't actually set the DC's pen when it is doing it, so it ends up using the default black pen. Normally this won't be a problem as the default background color is also black so you don't see it. However if you change to some other bg color you still end up with a visible black rectangle being drawn at that time.

···

On 6/15/10 2:30 PM, jantman wrote:

--
Robin Dunn
Software Craftsman