Hi Andrea et al,
When running the wxPython demo on Windows XP or Vista with the classic
windows theme checkboxes in the CustomTreeCtrl are not drawn right,
see attached screenshot.
Cheers, Frank
Hi Andrea et al,
When running the wxPython demo on Windows XP or Vista with the classic
windows theme checkboxes in the CustomTreeCtrl are not drawn right,
see attached screenshot.
Cheers, Frank
Hello,
On Tue, May 12, 2009 at 12:33 PM, Frank Niessink <frank@niessink.com> wrote:
Hi Andrea et al,
When running the wxPython demo on Windows XP or Vista with the classic
windows theme checkboxes in the CustomTreeCtrl are not drawn right,
see attached screenshot.
Do the checkboxes in the RenderNative demo also appear that way?
Regards,
Cody
Here is a patch that draws (quite ugly. see attachment) checkboxes
with the Classic theme, but still better than all-black squares
Cheers, Frank
### Eclipse Workspace Patch 1.0
#P taskcoach
Index: taskcoachlib/thirdparty/customtreectrl.py
2009/5/12 Frank Niessink <frank@niessink.com>:
Hi Andrea et al,
When running the wxPython demo on Windows XP or Vista with the classic
windows theme checkboxes in the CustomTreeCtrl are not drawn right,
===================================================================
--- taskcoachlib/thirdparty/customtreectrl.py (revision 1934)
+++ taskcoachlib/thirdparty/customtreectrl.py (working copy)
@@ -1925,7 +1925,7 @@
enabled=True, x=16, y=16):
"""Get a native looking checkbox or radio button bitmap
@keyword checkbox: Get a checkbox=True, radiobutton=False
- @keyword checked: contorl is marked or not
+ @keyword checked: control is marked or not
"""
bmp = wx.EmptyBitmap(x, y)
@@ -1942,9 +1942,9 @@
flag |= wx.CONTROL_DISABLED
if checkbox:
- render.DrawCheckBox(self, mdc, (0, 0, x, y), flag)
+ render.DrawCheckBox(self, dc, (0, 0, x, y), flag)
else:
- render.DrawRadioButton(self, mdc, (0, 0, x, y), flag)
+ render.DrawRadioButton(self, dc, (0, 0, x, y), flag)
mdc.SelectObject(wx.NullBitmap)
return bmp
Yup, it ain't pretty.
Cheers, Frank
2009/5/12 Cody Precord <codyprecord@gmail.com>:
Hello,
On Tue, May 12, 2009 at 12:33 PM, Frank Niessink <frank@niessink.com> wrote:
Hi Andrea et al,
When running the wxPython demo on Windows XP or Vista with the classic
windows theme checkboxes in the CustomTreeCtrl are not drawn right,
see attached screenshot.Do the checkboxes in the RenderNative demo also appear that way?
Hello,
Hello,
Hi Andrea et al,
When running the wxPython demo on Windows XP or Vista with the classic
windows theme checkboxes in the CustomTreeCtrl are not drawn right,
see attached screenshot.Do the checkboxes in the RenderNative demo also appear that way?
Yup, it ain't pretty.
(well arguably they all aren't pretty when the theming is turned off )
Actually that looks quite different than your previous screenshot in where they were black squares. It appears that when theming is turned off, the windows port falls back to the generic renderer for some controls.
The customtreectrl uses RendererNative to draw the checkboxes/radiobuttons so there may be an issue in its bitmap creation method.
Cody
On May 12, 2009, at 3:39 PM, Frank Niessink wrote:
2009/5/12 Cody Precord <codyprecord@gmail.com>:
On Tue, May 12, 2009 at 12:33 PM, Frank Niessink >> <frank@niessink.com> wrote:
Hi,
Hello,
Hello,
Hi Andrea et al,
When running the wxPython demo on Windows XP or Vista with the classic
windows theme checkboxes in the CustomTreeCtrl are not drawn right,
see attached screenshot.Do the checkboxes in the RenderNative demo also appear that way?
Yup, it ain't pretty.
(well arguably they all aren't pretty when the theming is turned off
)
Actually that looks quite different than your previous screenshot in where
they were black squares. It appears that when theming is turned off, the
windows port falls back to the generic renderer for some controls.The customtreectrl uses RendererNative to draw the checkboxes/radiobuttons
so there may be an issue in its bitmap creation method.
I believe it's a bug in RendererNative or a missing feature in the
Windows implementation. For instance, I am able to draw correctly
checkboxes by adding this line:
mdc.Clear()
in the checkbox/radiobutton drawing code in CustomTreeCtrl, but
radiobuttons are *never* drawn, whatever trick I do. This happens also
in the RendererNative demo, where radiobuttons do not show up (see
screenshot from Frank).
Now, I am applying this small change in SVN: however, the issue with
radiobuttons is still there. Is there any way to detect if the user is
running with no theme so that I can fall back to some default
radiobutton images?
Andrea.
"Imagination Is The Only Weapon In The War Against Reality."
http://xoomer.alice.it/infinity77/
On Wed, May 13, 2009 at 4:58 AM, Cody Precord wrote:
On May 12, 2009, at 3:39 PM, Frank Niessink wrote:
2009/5/12 Cody Precord <codyprecord@gmail.com>:
On Tue, May 12, 2009 at 12:33 PM, Frank Niessink <frank@niessink.com> >>> wrote:
Hi Frank,
Hi Andrea et al,
When running the wxPython demo on Windows XP or Vista with the classic
windows theme checkboxes in the CustomTreeCtrl are not drawn right,Here is a patch that draws (quite ugly. see attachment) checkboxes
with the Classic theme, but still better than all-black squaresCheers, Frank
### Eclipse Workspace Patch 1.0
#P taskcoach
Index: taskcoachlib/thirdparty/customtreectrl.py--- taskcoachlib/thirdparty/customtreectrl.py (revision 1934)
+++ taskcoachlib/thirdparty/customtreectrl.py (working copy)
@@ -1925,7 +1925,7 @@
enabled=True, x=16, y=16):
"""Get a native looking checkbox or radio button bitmap
@keyword checkbox: Get a checkbox=True, radiobutton=False
- @keyword checked: contorl is marked or not
+ @keyword checked: control is marked or not""" bmp = wx\.EmptyBitmap\(x, y\)
@@ -1942,9 +1942,9 @@
flag |= wx.CONTROL_DISABLEDif checkbox:
- render.DrawCheckBox(self, mdc, (0, 0, x, y), flag)
+ render.DrawCheckBox(self, dc, (0, 0, x, y), flag)
else:
- render.DrawRadioButton(self, mdc, (0, 0, x, y), flag)
+ render.DrawRadioButton(self, dc, (0, 0, x, y), flag)
Are you using the SVN version of CustomTreeCtrl? There is no "dc"
variable in that version... and the SVN one works for me on Windows XP
(except the radiobuttons, which are never drawn anyway).
Andrea.
"Imagination Is The Only Weapon In The War Against Reality."
http://xoomer.alice.it/infinity77/
On Tue, May 12, 2009 at 9:23 PM, Frank Niessink wrote:
2009/5/12 Frank Niessink <frank@niessink.com>:
I copied hypertreelist.py and customtreectrl.py from SVN in the Task
Coach SVN repository as I needed the latest versions, but the last
time I made a copy was probably a week ago or so. Anyway, I am happy
because checkboxes work. Task Coach doesn't use radio buttons, yet.
Thanks, Frank
2009/5/13 Andrea Gavana <andrea.gavana@gmail.com>:
Are you using the SVN version of CustomTreeCtrl? There is no "dc"
variable in that version... and the SVN one works for me on Windows XP
(except the radiobuttons, which are never drawn anyway).
Hello,
Hi,
Hello,
Hello,
Hi Andrea et al,
When running the wxPython demo on Windows XP or Vista with the classic
windows theme checkboxes in the CustomTreeCtrl are not drawn right,
see attached screenshot.Do the checkboxes in the RenderNative demo also appear that way?
Yup, it ain't pretty.
(well arguably they all aren't pretty when the theming is turned off
)
Actually that looks quite different than your previous screenshot in where
they were black squares. It appears that when theming is turned off, the
windows port falls back to the generic renderer for some controls.The customtreectrl uses RendererNative to draw the checkboxes/radiobuttons
so there may be an issue in its bitmap creation method.I believe it's a bug in RendererNative or a missing feature in the
Windows implementation. For instance, I am able to draw correctly
checkboxes by adding this line:mdc.Clear()
Not saying that it is without bugs but that was a missing step in the treectrls draw control method right
in the checkbox/radiobutton drawing code in CustomTreeCtrl, but
radiobuttons are *never* drawn, whatever trick I do. This happens also
in the RendererNative demo, where radiobuttons do not show up (see
screenshot from Frank).Now, I am applying this small change in SVN: however, the issue with
radiobuttons is still there. Is there any way to detect if the user is
running with no theme so that I can fall back to some default
radiobutton images?
Looking at the cpp implementation it would seem that when the theme handle is NULL its a no-op
<snip>
void wxRendererMSW::DrawRadioButton(wxWindow* win, wxDC& dc, const wxRect& rect, int flags)
{
#if wxUSE_UXTHEME
wxUxThemeHandle hTheme(win, L"BUTTON");
if ( !hTheme )
#endif
{
// ??? m_rendererNative.DrawRadioButton(win, dc, rect, flags);
return;
}
</snip>
If the // ??? line was uncommented it would fall back to the generic renderer as it does in the DrawCheckBox method so at least something would be drawn. I don't have a windows box setup right now with a dev environment so I can't verify this change.
I don't see an apparent way to check if the generic version is being used in a drawing operation. There is RendererNative.GetGeneric/GetDefault, I would say just let the generic one be drawn when themeing is not being used as they don't look 'completely' out of place and no computers come configured that way be default anymore so having lots of extra code for legacy support seems unnecessary, but anyway thats just my opinion.
Cody
On May 13, 2009, at 3:27 AM, Andrea Gavana wrote:
On Wed, May 13, 2009 at 4:58 AM, Cody Precord wrote:
On May 12, 2009, at 3:39 PM, Frank Niessink wrote:
2009/5/12 Cody Precord <codyprecord@gmail.com>:
On Tue, May 12, 2009 at 12:33 PM, Frank Niessink <frank@niessink.com >>>> > >>>> wrote:
Andrea Gavana wrote:
Hi,
Hello,
Hello,
Hi Andrea et al,
When running the wxPython demo on Windows XP or Vista with the classic
windows theme checkboxes in the CustomTreeCtrl are not drawn right,
see attached screenshot.Do the checkboxes in the RenderNative demo also appear that way?
Yup, it ain't pretty.
(well arguably they all aren't pretty when the theming is turned off
)
Actually that looks quite different than your previous screenshot in where
they were black squares. It appears that when theming is turned off, the
windows port falls back to the generic renderer for some controls.The customtreectrl uses RendererNative to draw the checkboxes/radiobuttons
so there may be an issue in its bitmap creation method.I believe it's a bug in RendererNative or a missing feature in the
Windows implementation. For instance, I am able to draw correctly
checkboxes by adding this line:mdc.Clear()
in the checkbox/radiobutton drawing code in CustomTreeCtrl, but
radiobuttons are *never* drawn, whatever trick I do. This happens also
in the RendererNative demo, where radiobuttons do not show up (see
screenshot from Frank).Now, I am applying this small change in SVN: however, the issue with
radiobuttons is still there. Is there any way to detect if the user is
running with no theme so that I can fall back to some default
radiobutton images?
There are two ways that an application can have a classic look, and AFAIK you can only detect one of them. The first is that the older, non-themed version of the commctrl DLL is being used. IOW, the same widget drawing code that was used in win2k is being used. The other case is that the themed version of the commctl DLL is being used, but the user has chosen the Classic theme.
You can check the version of the common controls DLL using wx.GetApp().GetComCtl32Version().
If the user has the Classic theme selected and there is something in the renderer that works with the default Luna theme and doesn't work with the Classic theme, then my guess would be that it is the theme's fault. (There have been a few problems with the Classic theme reported over the years.) wx is simply using the standard Windows Theme APIs, which redirect to the active theme's code for the drawing. Unfortunately I don't have any ideas for how to workaround this in a sane way.
On Wed, May 13, 2009 at 4:58 AM, Cody Precord wrote:
On May 12, 2009, at 3:39 PM, Frank Niessink wrote:
2009/5/12 Cody Precord <codyprecord@gmail.com>:
On Tue, May 12, 2009 at 12:33 PM, Frank Niessink <frank@niessink.com> >>>> wrote:
--
Robin Dunn
Software Craftsman