[2.9.3, wxMSW, VS2008] wxCheckBox's label displays incorrectly when added to toolbar

[Jon Marbach]

Hi there,

If you add a wxCheckBox to a toolbar, the label of the checkbox shows
up as a black box, or said another way, the background of the checkbox
control is drawn in black (and I can't seem to find a work-around.)

To reproduce, add this line to the toolbar sample at line 457 (just
after adding the combo box):

toolBar->AddControl( new wxCheckBox(toolBar, wxID_ANY, wxT("This is a
test"), wxT("Test") );

Thanks - and if anyone can identify a work around while we're waiting
for a fix, that would be helpful too. I've tried overriding
erase-background, and I've played with several background styles and
colors to no avail. (And for a really good time - try setting
wxCLIP_CHILDREN on the toolbar!)

Thanks,
Jon

[Jon M]

Sorry, the correct line of code is:

 

toolBar->AddControl( new wxCheckBox(toolBar, wxID_ANY, wxT("This is a

test")), wxT("Test") );

Jon

[Vadim Zeitlin]

On Thu, 3 May 2012 22:44:42 -0600 Jon Marbach wrote:

JM> If you add a wxCheckBox to a toolbar, the label of the checkbox shows
JM> up as a black box, or said another way, the background of the checkbox
JM> control is drawn in black (and I can't seem to find a work-around.)
JM>
JM> To reproduce, add this line to the toolbar sample at line 457 (just
JM> after adding the combo box):
JM>
JM> toolBar->AddControl( new wxCheckBox(toolBar, wxID_ANY, wxT("This is a
JM> test"), wxT("Test") );

Yes, I can see this but I don't have any immediate fix. This clearly is
a general bug in wxToolBar handling of transparent children (i.e. those
whose HasTransparentBackground() returns true) but I'm not sure what it is
right now.

Dimitri, would you have any idea about this by chance, as you looked at
this code just recently?

Anyhow, please open a Trac ticket for this so that it doesn't get
forgotten, thanks in advance.

JM> Thanks - and if anyone can identify a work around while we're waiting
JM> for a fix, that would be helpful too.

A simple work around is to make a checkbox owner drawn (and hence non
transparent) by changing its colour, e.g. this

wxCheckBox* chk = new wxCheckBox(toolBar, wxID_ANY, "This is a test");
chk->SetForegroundColour(*wxBLUE);
toolBar->AddControl(chk, "Test");

works. It's obviously not great but if you use a colour very similar to the
normal text colour (e.g. offset one of the colour components by 1) it
should look almost exactly as it should.

Regards,
VZ

[Dimitri Schoolwerth]

On Fri, May 4, 2012 at 1:43 PM, Vadim Zeitlin <va...@wxwidgets.org> wrote:
> On Thu, 3 May 2012 22:44:42 -0600 Jon Marbach wrote:
>
> JM> If you add a wxCheckBox to a toolbar, the label of the checkbox shows
> JM> up as a black box, or said another way, the background of the checkbox
> JM> control is drawn in black (and I can't seem to find a work-around.)
> JM>
> JM> To reproduce, add this line to the toolbar sample at line 457 (just
> JM> after adding the combo box):
> JM>
> JM> toolBar->AddControl( new wxCheckBox(toolBar, wxID_ANY, wxT("This is a
> JM> test"), wxT("Test") );
>
>  Yes, I can see this but I don't have any immediate fix. This clearly is
> a general bug in wxToolBar handling of transparent children (i.e. those
> whose HasTransparentBackground() returns true) but I'm not sure what it is
> right now.
>
>  Dimitri, would you have any idea about this by chance, as you looked at
> this code just recently?

I have been looking into this last night, but not having much luck yet
after some experimenting. All I can say (assuming it's the same
problem) is that it was introduced in r62971 and the relevant ticket
is #12307 (so there's no need to open a new one). Also when I #undef
wxHAS_MSW_BACKGROUND_ERASE_HOOK the entire background is black, don't
know if that's related but I was thinking if I can fix that then
hopefully the problem with black pixels and controls in a toolbar
would also be solved.

> JM> Thanks - and if anyone can identify a work around while we're waiting
> JM> for a fix, that would be helpful too.
>
>  A simple work around is to make a checkbox owner drawn (and hence non
> transparent) by changing its colour, e.g. this
>
>        wxCheckBox* chk = new wxCheckBox(toolBar, wxID_ANY, "This is a test");
>        chk->SetForegroundColour(*wxBLUE);
>        toolBar->AddControl(chk, "Test");

I also noticed, with a wxComboBox and to some extent a wxButton, the
black pixels disappear when first hovering over another toolbar item
and then the item with black pixels. I thought maybe the community
addition about repainting at
http://msdn.microsoft.com/en-us/library/windows/desktop/bb760439%28v=vs.85%29.aspx
is relevant to that.


Regards,
Dimitri

[Vadim Zeitlin]

On Fri, 4 May 2012 17:23:59 +0400 Dimitri Schoolwerth wrote:

DS> I have been looking into this last night, but not having much luck yet
DS> after some experimenting. All I can say (assuming it's the same
DS> problem) is that it was introduced in r62971 and the relevant ticket
DS> is #12307 (so there's no need to open a new one).

Thanks for the reference, I completely forgot about this one but it's true
that it looks like the same problem.

I don't understand however why is it broken for checkboxes too. Looking at
the code in wxToolBar::MSWGetBgBrushForChild(), we should be returning the
correct brush for it (as its HasTransparentBackground() returns true) so
its background should be painted. It might be worth to use some more easily
visible colour (e.g. *wxRED) in wxToolBar::MSWGetToolbarBgBrush() and
sprinkle the code with Update()+Sleep() calls to see how is it really being
drawn (not sure if this is going to work under Win7 with its double
buffering but it worked under XP).

DS> Also when I #undef wxHAS_MSW_BACKGROUND_ERASE_HOOK the entire
DS> background is black, don't know if that's related but I was thinking if
DS> I can fix that then hopefully the problem with black pixels and
DS> controls in a toolbar would also be solved.

We can't use TBSTYLE_FLAT and TBSTYLE_TRANSPARENT if we don't erase the
background so the actual bug here is probably that the code in
wxToolBar::MSWGetStyle() doesn't test for wxHAS_MSW_BACKGROUND_ERASE_HOOK.
IOW I don't think it's the same problem... But I definitely could be wrong.


DS> I also noticed, with a wxComboBox and to some extent a wxButton, the
DS> black pixels disappear when first hovering over another toolbar item
DS> and then the item with black pixels. I thought maybe the community
DS> addition about repainting at
DS> http://msdn.microsoft.com/en-us/library/windows/desktop/bb760439%28v=vs.85%29.aspx
DS> is relevant to that.

Not sure how/why?
VZ

[Dimitri Schoolwerth]

On Fri, May 4, 2012 at 6:32 PM, Vadim Zeitlin <va...@wxwidgets.org> wrote:
> On Fri, 4 May 2012 17:23:59 +0400 Dimitri Schoolwerth wrote:
>
>  I don't understand however why is it broken for checkboxes too. Looking at
> the code in wxToolBar::MSWGetBgBrushForChild(), we should be returning the
> correct brush for it (as its HasTransparentBackground() returns true) so
> its background should be painted. It might be worth to use some more easily
> visible colour (e.g. *wxRED) in wxToolBar::MSWGetToolbarBgBrush() and
> sprinkle the code with Update()+Sleep() calls to see how is it really being
> drawn (not sure if this is going to work under Win7 with its double
> buffering but it worked under XP).

I noticed that if I let wxFrame erase the toolbar background again
(reverting the changes in DoEraseBackground at
http://trac.wxwidgets.org/changeset/62971#file3 ) then that at least
changes the black colour into, I assume, the frame's background
colour. Does that provide you with a hint? Maybe the black is
something uninitialised (with a button in the toolbar I also sometimes
see the background pixels changing colour after having removed the
black pixels by hovering over a normal item and then the offending
item) and we do need to do some drawing behind the toolbar also.

> DS> Also when I #undef wxHAS_MSW_BACKGROUND_ERASE_HOOK the entire
> DS> background is black, don't know if that's related but I was thinking if
> DS> I can fix that then hopefully the problem with black pixels and
> DS> controls in a toolbar would also be solved.
>
>  We can't use TBSTYLE_FLAT and TBSTYLE_TRANSPARENT if we don't erase the
> background so the actual bug here is probably that the code in
> wxToolBar::MSWGetStyle() doesn't test for wxHAS_MSW_BACKGROUND_ERASE_HOOK.
> IOW I don't think it's the same problem... But I definitely could be wrong.

I think that at least it's the same black pixels though: when I revert
the change mentioned above and undefine
wxHAS_MSW_BACKGROUND_ERASE_HOOK then all the black pixels also
disappear and are turned into the frame's background colour.

> DS> I also noticed, with a wxComboBox and to some extent a wxButton, the
> DS> black pixels disappear when first hovering over another toolbar item
> DS> and then the item with black pixels. I thought maybe the community
> DS> addition about repainting at
> DS> http://msdn.microsoft.com/en-us/library/windows/desktop/bb760439%28v=vs.85%29.aspx
> DS> is relevant to that.
>
>  Not sure how/why?

I just saw the words repainting and activating there, which seemed
related to how the black pixels disappear after some hovering.
Apparently it's not :).


Regards,
Dimitri

[Jon M]

Thanks for looking into this guys - sorry to hear there's no easy fix. I'll give setting the foregrond color a try.