The below function relies on the image having the same background colour as TColor::Sys3dFace, but given that this colour changes with the theme makes this function next to useless (the bitmaps wont change so the mask breaks). Also I think the colour is supposed to be the MaskedColour variable. The Syscolor wouldn't really serve a purpose because the transparency is the same colour as syscolor!
Also, is there a way to set the masked colour from TBUttonGadget... I don't think there is. I ended up copying the copde fomr OWL and throwing it into my app so that I could change the mask colour.
void
TUIFace::BuildMask(TDC& maskDC, const TPoint& maskDst, const TSize& maskSize,
TDC& glyphDC, const TRect& glyphRect,
const TColor& maskedColor)
{
//BuildMask(maskDC, dstPt, maskRect.Size(), memDC, glyphSrcRect, maskColor);
OutputDebugString("\nBuildMask()");
maskDC.PatBlt(0, 0, maskSize.cx, maskSize.cy, WHITENESS);
if (maskedColor != TColor::None) {
TColor bkColor = glyphDC.SetBkColor(TColor::Sys3dFace); // VH: Should be maskedColor? <-------------------------------PROBABLY THE BUG
maskDC.BitBlt(maskDst.x, maskDst.y, glyphRect.Width(), glyphRect.Height(),
glyphDC, glyphRect.left, glyphRect.top, SRCCOPY);
glyphDC.SetBkColor(bkColor);
}
}
1 - Please LOG-IN before report a bug.
2 - What version of OWLNext are you using. I´ve tested with OWLNext 6.20.10
and the TButtonGadget 'works for me'.
I'm ataching two images with differents 'themes'.
The second one is also modified so '3D objects' are painted with that fuxia and the TButtonGadget still draws fine.
Notice also I've included the Photoshop toolbar and it also it's painted as the 'smile' TButtonGadet of the demo application.
I've used the $(OWLROOT)\examples\Classes\gadgets demo.
3- I've builded OWLNext with your suggested modification and I didn't notice any effect.
If you are using other control that TGadgetButton please advice.
4-As I know , the color used for mask is TColor::ltGray (192,192,192).
At least for TGlyphButton.
TButtonGadget themes 'works for me' with OWLNext 6.20.10
While the reported issue seems like an obvious bug, and I personally put in that comment in the code, I didn't correct it, because I suspected OWLNext and user code may depend on it. Further investigation has shown that this is the case (see below). Code may rely on TColor::Sys3dFace being used as the mask colour (the bug), even though a different colour has been passed as the face background colour (the default is white if none is passed).
As the original poster of the issue points out, TColor::Sys3dFace varies with the user interface settings, while the bitmap background colour (the mask colour) is inherently fixed as part of the bitmap resource. Still, OWL has fixed on Sys3dFace as the mask colour and consistently uses it everywhere. So how does OWL make it work?
OWL actually maps the background colour in a bitmap before it is drawn to enable proper masking. See TDib::MapUIColors and its use in TButtonGadget::GetGlyphDib. MapUIColors require that the author of the bitmap always uses TColor::LtGray as the background colour for the glyphs. Elsewhere, TGlyphButton depend on TBtnBitmap to do something similar; TBtnBitmap::UpdateFaceColor maps the current face colour to the current Sys3dFace colour.
That said, a good question to ask is whether this is a wise design. It seems easier and much more intuitive to just make the mask colour a parameter. I guess this was a later improvement to the OWL code, but which unfortunately was left with that bug.
I recommend that we fix it, but I do not have the opportunity to do full regression testing. Here is a little more information about the scope of the problem:
draw glyphs.
text only.
the correct (mapped) background colour (TColor::Sys3dFace).
set the background colour (hence incorrectly gets the default white).
Hence the only ill effect of correcting the bug seems to be that it may cause TNoteTab to not properly mask bitmaps. This can be solved by changing the default argument for the TUIFace constructor to use Sys3dFace (as actually suggested by a comment in the code), or simply by passing the correct background colour to the TUIFace constructors in TNoteTab::Paint. I prefer the latter since it is more explicit. Or both.
If you want to test this I have posted a patch to the mailing list. It corrects the bug and fixes TNoteTab. You need to test drawing glyphs using TUIFace on a variety of backgrounds, including non-standard Windows colours. Ideally it should be tested with the Windows colours changing on the fly. You also have to test that all other affected code in OWLNext continues to work; see the list above.
PS. Note that TUIFace::PaintBm was patched for theme support in version 6.20.7. It had a separate bug with regard to proper masking. The code now uses TDC::MaskBlt. It was in the course of that patch that I researched the code and put in the comment in TUIFace::BuildMask about the likely bug in the code.
Regards,
Vidar Hasfjord
Thanks, I think we had a version further back 20.4, maybe that could explain why I had problems, maybe I just got caught out by a red herring while looking for the problem.
I did look on http://owlnext.sourceforge.net/discuss.html for the change before posting but did not see anything mentioned about it or maybe I just missed it, it may have been archived.
ps I will log in next time I post something.
Thanks
Fixed in 6.21.11
Fix was included 6.30