Owner Draw STATIC Window with XP Themes

[Jonathan Wood]

I have existing code that draws a sample font on a STATIC window in a dialog
box. This code has worked flawlessly for years.

However, when I make my application themed on XP, my OnEraseBkgnd handler is
still filling the background with the old COLOR_3DFACE color.

I tried removing my OnEraseBkgnd handler and, in fact, it draws just fine.
Unfortunately, when I invalidate the window to draw a new font, it does not
erase the old font.

I've played with the IsThemeActive and a few others but found them
completely unreliable.

Since ::GetSysColor(COLOR_3DFACE) returns a wrong value when my application
is themed, can anyone offer any other suggestions for clearing the
background of this window?

Thanks.

--
Jonathan Wood
SoftCircuits
http://www.softcircuits.com
Available for consulting: http://www.softcircuits.com/jwood/resume.htm

[Doug Harrison [MVP]]

Jonathan Wood wrote:

>I have existing code that draws a sample font on a STATIC window in a dialog
>box. This code has worked flawlessly for years.
>
>However, when I make my application themed on XP, my OnEraseBkgnd handler is
>still filling the background with the old COLOR_3DFACE color.
>
>I tried removing my OnEraseBkgnd handler and, in fact, it draws just fine.
>Unfortunately, when I invalidate the window to draw a new font, it does not
>erase the old font.
>
>I've played with the IsThemeActive and a few others but found them
>completely unreliable.

I use IsAppThemed to determine whether to use theme functions or traditional
Windows API.

>Since ::GetSysColor(COLOR_3DFACE) returns a wrong value when my application
>is themed, can anyone offer any other suggestions for clearing the
>background of this window?

See DrawThemeParentBackground and maybe DrawThemeBackground.

--
Doug Harrison
Microsoft MVP - Visual C++

[Jonathan Wood]

Doug,

> I use IsAppThemed to determine whether to use theme functions or
traditional
> Windows API.

Well, IsAppThemed will return TRUE even though a manifest resource is not
present so I questioned its reliability. But I guess you know if you are
including a manifest resource or not. Hopefully, it is reliable given that
the manifest is included.

I put together a class for this stuff that uses LoadLibrary to load
UxTheme.dll. This way, the application can still work on older versions of
Windows. Did you do something like this as well?

> >Since ::GetSysColor(COLOR_3DFACE) returns a wrong value when my
application
> >is themed, can anyone offer any other suggestions for clearing the
> >background of this window?
>
> See DrawThemeParentBackground and maybe DrawThemeBackground.

Well, DrawThemeParentBackground didn't seem appropriate because it seems to
assume I am drawing the parent underneath a child window, which I'm not
doing. And DrawThemeBackground seems closer but requires me to specify the
theme. I'm a bit surprised that there isn't a way to do this using the
default theme. For example, EnableThemeDialogTexture seems to work
automatically with the current theme.

Hmmm... Still looking...

[Doug Harrison [MVP]]

Jonathan Wood wrote:

>Well, IsAppThemed will return TRUE even though a manifest resource is not
>present so I questioned its reliability. But I guess you know if you are
>including a manifest resource or not. Hopefully, it is reliable given that
>the manifest is included.

IME, it is. You can test by turning themes off on a system-wide basis and
also just for your specific application through the .exe's properties.

>I put together a class for this stuff that uses LoadLibrary to load
>UxTheme.dll. This way, the application can still work on older versions of
>Windows. Did you do something like this as well?

Yep. I either did that or delayloaded uxtheme.dll, taking care not to call
theme functions unless running on XP or better. (This isn't always the best
way to handle this sort of situation, but as MS won't be adding themes to
Windows younger than XP, it's reasonably adequate.)

>Well, DrawThemeParentBackground didn't seem appropriate because it seems to
>assume I am drawing the parent underneath a child window, which I'm not
>doing. And DrawThemeBackground seems closer but requires me to specify the
>theme. I'm a bit surprised that there isn't a way to do this using the
>default theme. For example, EnableThemeDialogTexture seems to work
>automatically with the current theme.
>
>Hmmm... Still looking...

It's essential that transparent child controls use
DrawThemeParentBackground. For example, here's a function from my ownerdraw
button class, which supports "hover" buttons, that is, buttons that appear
to be ordinary labels until pointed to, when they acquire a push button
appearance. I use these buttons for "active labels", that is, labels that
open up menus and alternate editors, such as a multiline alternative to a
single line edit control, etc. Note this means that when displayed as a
plain label, the parent background shows through, and since the parent is
often a property page with a gradient background, the only way to draw the
background is to use DrawThemeParentBackground:

void
OdButton::DrawBackground(CDC& dc, const DRAWITEMSTRUCT& dis)
{
if (m_hTheme)
{
DrawThemeParentBackground(m_hWnd, dc.m_hDC, 0);
DrawThemeBackground(
m_hTheme,
dc.m_hDC,
BP_PUSHBUTTON,
GetThemeButtonState(dis),
&dis.rcItem,
0);
}
else
FillRect(dc.m_hDC, &dis.rcItem, HBRUSH(COLOR_BTNFACE+1));
}

Here's the function which helps maintain the theme state, called during
PreSubclassWindow and in response to WM_THEMECHANGED:

void
OdButton::UpdateTheme()
{
if (OsVersion::AtLeastXP())
{
CloseThemeData(m_hTheme);
m_hTheme = (UserEx::IsAppThemed())
? OpenThemeData(m_hWnd, L"button")
: 0;

[Jeff Partch [MVP]]

"Doug Harrison [MVP]" <d...@mvps.org> wrote in message
news:lop5p05fiqtce38g1...@4ax.com...

> Jonathan Wood wrote:
>
> >Well, IsAppThemed will return TRUE even though a manifest resource is not
> >present so I questioned its reliability. But I guess you know if you are
> >including a manifest resource or not. Hopefully, it is reliable given
that
> >the manifest is included.
>
> IME, it is. You can test by turning themes off on a system-wide basis and
> also just for your specific application through the .exe's properties.

Don't ge too annoyed by my jumping in here, but I think you are both right.
My recollected understanding of IsThemeActive and IsAppThemed is:

1) they will both return TRUE when themes are active system wide
2) except that IsAppThemed will return FALSE only in the case where themes
are disabled in the compatibility properties for the application.

Neither concerns itself with whether this particular app has a manifest and
is supposed to use themes and neither is particularly determinate as to
whether this particular control is supposed to use themes -- only that it
*could* -- not not that it *should*. That leaves the similarly flawed
GetThemeAppProperties, and GetWindowTheme which I discuss below.

Another hack I use for the standard windows controls and which I've posted
before is to test whether the GetClassLongPtr(hWnd, GCLP_HMODULE) is equal
to GetModuleHandle(_T("Comctl32.dll"), and which I think does consider the
"has a manifest" issue, but probably not the
SetThemeAppProperties(~STAP_ALLOW_CONTROLS) and SetWindowTheme(L"", L"")
cases. And IIRC, there are folks doing things with the activation context to
disable theming after the fact even in an otherwise themed app with a
manifest.

> Here's the function which helps maintain the theme state, called during
> PreSubclassWindow and in response to WM_THEMECHANGED:
>
> void
> OdButton::UpdateTheme()
> {
> if (OsVersion::AtLeastXP())
> {
> CloseThemeData(m_hTheme);
> m_hTheme = (UserEx::IsAppThemed())
> ? OpenThemeData(m_hWnd, L"button")
> : 0;
> }
> }

FYI, According to Dave Anderson, Microsoft Developer Support, you can't
really do this, Doug...

"
> You should open a theme once per window... open it when the window is
> created and close the handle when the window is destroyed. There is a
limit
> of 64K handles per process. The bug is when this limit is reached,
> OpenThemeData does not return NULL.
"

Even allowing an exception for WM_THEMECHANGED, you're now doing it twice
per window. :)

Presumably a subclass should use GetWindowTheme to obtain, "the most recent
theme handle from OpenThemeData". But...

Back in July, I reported what I thought was a bug regarding
GetWindowTheme...

"So here's the situation: I'm working on this NM_CUSTOMDRAW handler for a
themed pushbutton on XPSP1. I'm using VC7.1 and a MFC7 dialog-based
application (although I don't believe MFC is the culprit). Now, in my
NM_CUSTOMDRAW handler, I have occasion to call GetWindowTheme..., but every
time the
button gains and looses the focus the call returns NULL".

So if the question the control is asking is, "as an independent component of
any application running on any OS under any externally imposed or inherited
variable conditions, am I supposed to be using themes right now"?. my
subjective conclusion is that there is no *one* API that answers this
question, and even in consort all of them together may not answer the
question with absolute certainty. At best, you end up with an increasingly
more educated guess. FWIW.

:)

--
Jeff Partch [VC++ MVP]

[Jonathan Wood]

Doug,

> It's essential that transparent child controls use
> DrawThemeParentBackground.

Right, that just wasn't my situation.

But thanks to your suggestions and some other code I found on the Web,
DrawThemeBackground did in fact turn out to be what I needed. Along with
OpenThemeData, I think I have a reliable approach that will work on older
versions of Windows.

In fact, DrawThemeBackground can be used to draw themed buttons as well,
which was another thing I was trying to solve. So I'm well on my way.

Your code looks interesting, I'll have to look into the transparent approach
sometime.

[Jonathan Wood]

Jeff,

> Don't ge too annoyed by my jumping in here, but I think you are both
right.
> My recollected understanding of IsThemeActive and IsAppThemed is:
>
> 1) they will both return TRUE when themes are active system wide
> 2) except that IsAppThemed will return FALSE only in the case where themes
> are disabled in the compatibility properties for the application.
>
> Neither concerns itself with whether this particular app has a manifest
and
> is supposed to use themes and neither is particularly determinate as to
> whether this particular control is supposed to use themes -- only that it
> *could* -- not not that it *should*.

Right. This seems consistent with what I'm seeing.

> > Here's the function which helps maintain the theme state, called during
> > PreSubclassWindow and in response to WM_THEMECHANGED:
> >
> > void
> > OdButton::UpdateTheme()
> > {
> > if (OsVersion::AtLeastXP())
> > {
> > CloseThemeData(m_hTheme);
> > m_hTheme = (UserEx::IsAppThemed())
> > ? OpenThemeData(m_hWnd, L"button")
> > : 0;
> > }
> > }
>

> FYI, According to Dave Anderson, Microsoft Developer Support, you can't
> really do this, Doug...
>
> "
> > You should open a theme once per window... open it when the window is
> > created and close the handle when the window is destroyed. There is a
> limit
> > of 64K handles per process. The bug is when this limit is reached,
> > OpenThemeData does not return NULL.
> "
>
> Even allowing an exception for WM_THEMECHANGED, you're now doing it twice
> per window. :)

Well, that answers a question I was wondering about: whether it is okay to
open the theme data everytime you are redrawing the window. I've seen that
done many times in code I've seen on the Web. Apparently, it is better to
open it only once (even though opening it each time seems to work just
fine).

But I might be with Doug here. You must get new theme data in order to react
to a theme change, don't you? And Doug is closing the original theme before
opening a new one. It seems to me he is following Dave's advice as closely
as is practical.

[Jeff Partch]

"Jonathan Wood" <jw...@softcircuits.com> wrote in message
news:eYX5C%23AyEH...@TK2MSFTNGP14.phx.gbl...

> > FYI, According to Dave Anderson, Microsoft Developer Support, you can't
> > really do this, Doug...
> >
> > "
> > > You should open a theme once per window... open it when the window is
> > > created and close the handle when the window is destroyed. There is a
> > limit
> > > of 64K handles per process. The bug is when this limit is reached,
> > > OpenThemeData does not return NULL.
> > "
> >
> > Even allowing an exception for WM_THEMECHANGED, you're now doing it
twice
> > per window. :)
>
> Well, that answers a question I was wondering about: whether it is okay to
> open the theme data everytime you are redrawing the window. I've seen that
> done many times in code I've seen on the Web. Apparently, it is better to
> open it only once (even though opening it each time seems to work just
> fine).

I've not investigated the veracity of what Dave said in his post, but
inasmuch as the documentation is so poor and the whole scheme so buggy, I
tend to take anything an MS representative says about working with the theme
API seriously enough. I also can't imagine that what he says to do is the
same thing as saying OpenThemeData as much as you want as long as you match
it with a CloseThemeData.

>
> But I might be with Doug here. You must get new theme data in order to
react
> to a theme change, don't you? And Doug is closing the original theme
before
> opening a new one. It seems to me he is following Dave's advice as closely
> as is practical.

Well, why it violates Dave's 'rule' is that the button WNDCLASS calls
OpenThemeData when it gets WM_CREATE and Doug does it again in
PreSubclassWindow, and then in response to WM_THEMECHANGED it's the same
thing -- the button does it and then the subclass does it again. In either
event, that's twice per window, and once per subclass is not the same thing
as once per window. Now extrapolate it to a subclass of a subclass (of a
subclass...), and you can at least imagine why it might not be such a good
practice.

[Jonathan Wood]

Jeff,

> Well, why it violates Dave's 'rule' is that the button WNDCLASS calls
> OpenThemeData when it gets WM_CREATE and Doug does it again in
> PreSubclassWindow, and then in response to WM_THEMECHANGED it's the same
> thing -- the button does it and then the subclass does it again. In either
> event, that's twice per window, and once per subclass is not the same
thing
> as once per window. Now extrapolate it to a subclass of a subclass (of a
> subclass...), and you can at least imagine why it might not be such a good
> practice.

I guess I was originally thinking that Dave was simply making the point that
he didn't think it was a good idea to open the theme each time you were
updating the window and offered the idea of opening and closing it as the
window is created and destroyed, perhaps without considering the issue of
themes changes, which would require additional code.

But I guess you're saying that the original button code is doing it as well
in addition to his code that has subclassed the button. But wouldn't this
happen anyway, even if you opened the theme data when the window was
created?

[Jeff Partch]

"Jonathan Wood" <jw...@softcircuits.com> wrote in message

news:u94o5gBy...@TK2MSFTNGP15.phx.gbl...

> I guess I was originally thinking that Dave was simply making the point
that
> he didn't think it was a good idea to open the theme each time you were
> updating the window and offered the idea of opening and closing it as the
> window is created and destroyed, perhaps without considering the issue of
> themes changes, which would require additional code.

Yes, that's what I suspect as well. One has to allow for WM_THEMECHANGED
when implementing a WNDCLASS, there is no other option. So consider that
what Dave said was once per window when it gets WM_CREATE or again when it
gets WM_THEMECHANGED.

>
> But I guess you're saying that the original button code is doing it as
well
> in addition to his code that has subclassed the button.

Yes, that's what I'm trying to say. :)

> But wouldn't this
> happen anyway, even if you opened the theme data when the window was
> created?

I don't think I understand where you've gone with this, Jonathan, but it
wouldn't happen if the subclass never called OpenThemeData.

[Jonathan Wood]

Jeff,

> > But wouldn't this
> > happen anyway, even if you opened the theme data when the window was
> > created?
>
> I don't think I understand where you've gone with this, Jonathan, but it
> wouldn't happen if the subclass never called OpenThemeData.

Sure, but then how would you draw with that theme data? In other words, if
the original button code in Windows is calling OpenThemeData, how can your
subclass code ever draw using themes without opening up a second HTHEME?

It would seem to me that a second HTHEME is required in this case, and then
I don't see how it matters if you opened it during WM_CREATE or during the
first pass only through your paint code.

[Doug Harrison [MVP]]

Jeff Partch [MVP] wrote:

>"Doug Harrison [MVP]" <d...@mvps.org> wrote in message
>news:lop5p05fiqtce38g1...@4ax.com...
>> Jonathan Wood wrote:
>>
>> >Well, IsAppThemed will return TRUE even though a manifest resource is not
>> >present so I questioned its reliability. But I guess you know if you are
>> >including a manifest resource or not. Hopefully, it is reliable given
>that
>> >the manifest is included.
>>
>> IME, it is. You can test by turning themes off on a system-wide basis and
>> also just for your specific application through the .exe's properties.
>
>Don't ge too annoyed by my jumping in here, but I think you are both right.
>My recollected understanding of IsThemeActive and IsAppThemed is:
>
>1) they will both return TRUE when themes are active system wide
>2) except that IsAppThemed will return FALSE only in the case where themes
>are disabled in the compatibility properties for the application.
>
>Neither concerns itself with whether this particular app has a manifest and
>is supposed to use themes and neither is particularly determinate as to
>whether this particular control is supposed to use themes -- only that it
>*could* -- not not that it *should*. That leaves the similarly flawed
>GetThemeAppProperties, and GetWindowTheme which I discuss below.

I'm with you so far. ISTR a problem with IsThemeActive, causing me to use
IsAppThemed, which has been reliable for me in apps known to have a
manifest.

>Another hack I use for the standard windows controls and which I've posted
>before is to test whether the GetClassLongPtr(hWnd, GCLP_HMODULE) is equal
>to GetModuleHandle(_T("Comctl32.dll"), and which I think does consider the
>"has a manifest" issue, but probably not the
>SetThemeAppProperties(~STAP_ALLOW_CONTROLS) and SetWindowTheme(L"", L"")
>cases. And IIRC, there are folks doing things with the activation context to
>disable theming after the fact even in an otherwise themed app with a
>manifest.

Example? I'm so not familiar with activation contexts. I guess if you were
going for full generality, you'd have to worry about those things.

>> Here's the function which helps maintain the theme state, called during
>> PreSubclassWindow and in response to WM_THEMECHANGED:
>>
>> void
>> OdButton::UpdateTheme()
>> {
>> if (OsVersion::AtLeastXP())
>> {
>> CloseThemeData(m_hTheme);
>> m_hTheme = (UserEx::IsAppThemed())
>> ? OpenThemeData(m_hWnd, L"button")
>> : 0;
>> }
>> }
>
>FYI, According to Dave Anderson, Microsoft Developer Support, you can't
>really do this, Doug...
>
>"
>> You should open a theme once per window... open it when the window is
>> created and close the handle when the window is destroyed. There is a
>limit
>> of 64K handles per process. The bug is when this limit is reached,
>> OpenThemeData does not return NULL.
>"
>
>Even allowing an exception for WM_THEMECHANGED, you're now doing it twice
>per window. :)

Can't do what? Each OpenThemeData has a matching CloseThemeData. The
WM_THEMECHANGED docs say:

<q>
To release an existing theme handle, call CloseThemeData. To acquire a new
theme handle, use OpenThemeData.

Following the WM_THEMECHANGED broadcast, any existing theme handles are
invalid. A theme-aware window should release any pre-existing theme handles
when it receives the WM_THEMECHANGED message. It may optionally open a new
theme handle if the IsThemeActive function returns TRUE.
</q>

Then there's the CloseThemeData docs:

<q>
The CloseThemeData function should be called when a window that has a visual
style applied is destroyed. Also this function is used when a window
receives a WM_THEMECHANGED message followed by an attempt to create a new
theme data handle.
</q>

Now, if you're saying each HWND maintains a set of HTHEMEs opened on it,
such that it's an error to open the same theme twice on a window, then I'd
say, "Well, CloseThemeData doesn't take an HWND, it takes only an HTHEME, so
how can this list be maintained?" The only potential way I can see to
"revoke" an HTHEME is to call OpenThemeData on an imaginary theme, but that
would be exceedingly bizarre.

I just wrote a little app to determine if the HTHEMEs are reference-counted,
and it appears they are. This program has a dialog box with OK and Cancel
buttons, with the OK button subclassed. I called OpenThemeData once in my
button class's PreSubclassWindow, and it didn't mess up (drew solid black
rectangle for the OK and Cancel buttons) until I called CloseThemeData three
times. I deleted the Cancel button, and it messed up after calling
CloseThemeData twice. Finally, I got rid of the OpenThemeData call, and it
messed up after calling CloseThemeData once on the HTHEME returned by
GetWindowTheme for the OK button. This is consistent with what I've observed
for the 3+ years I've been using themes, namely, the approach I'm using
works fine, because the HTHEMEs are reference-counted.

Moreover, consider:

Using Windows XP Visual Styles
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/shellcc/platform/commctls/userex/cookbook.asp

<q>
The following code sample demonstrates how to draw a button control.

hTheme = OpenThemeData(hwndButton, "Button");
...
DrawMyControl(hDC, hwndButton, hTheme, iState);
...
if (hTheme)
{
CloseTheme(hTheme);
}
</q>

I've actually done the following for my hover button, which overrides the
DrawBackground function I presented earlier to use the toolbar style for the
"show button" state, which looks better:

<q>
You can use parts from other controls and render each part separately. For
example, for a calendar control that consists of a grid, you can treat each
square formed by the grid as a toolbar button. Do the following to program
the squares as toolbar buttons.
Call OpenThemeData as follows:
OpenThemeData (hwnd, "Toolbar");
...
You can mix and match control parts by calling OpenThemeData multiple times
for a given control and using the appropriate theme handle to draw different
parts.
</q>

This all implies you needn't worry about any themes already opened on the
control.

>Presumably a subclass should use GetWindowTheme to obtain, "the most recent
>theme handle from OpenThemeData". But...
>
>Back in July, I reported what I thought was a bug regarding
>GetWindowTheme...
>
>"So here's the situation: I'm working on this NM_CUSTOMDRAW handler for a
>themed pushbutton on XPSP1. I'm using VC7.1 and a MFC7 dialog-based
>application (although I don't believe MFC is the culprit). Now, in my
>NM_CUSTOMDRAW handler, I have occasion to call GetWindowTheme..., but every
>time the
>button gains and looses the focus the call returns NULL".
>
>So if the question the control is asking is, "as an independent component of
>any application running on any OS under any externally imposed or inherited
>variable conditions, am I supposed to be using themes right now"?. my
>subjective conclusion is that there is no *one* API that answers this
>question, and even in consort all of them together may not answer the
>question with absolute certainty. At best, you end up with an increasingly
>more educated guess. FWIW.

The Visual Styles documentation is among the worst in MSDN. It was horribly
incomplete and ambiguous when it first came out, and reviewing it now, it
seems not to have improved much. For my purposes, IsAppThemed() has worked
reliably to determine if controls should be themed, but then again, I don't
have any controls that have disabled themes with SetWindowTheme, and as
mentioned earlier, I'm not concerned with apps that may not have a manifest.
These considerations aside, I've observed zero problems with the method I've
been using for 3+ years, and I've had no reports of any problems with it for
apps that run on Windows 9x and NT4 and later. The documentation gives no
hint the approach shouldn't work; on the contrary, it gives examples
indicating it should work. The test app I just wrote seems to confirm the
approach is sound. So as long as it ain't broke... :)

[Jeff Partch]

"Jonathan Wood" <jw...@softcircuits.com> wrote in message

news:eXw6WwBy...@TK2MSFTNGP15.phx.gbl...

> Jeff,
>
> > > But wouldn't this
> > > happen anyway, even if you opened the theme data when the window was
> > > created?
> >
> > I don't think I understand where you've gone with this, Jonathan, but it
> > wouldn't happen if the subclass never called OpenThemeData.
>
> Sure, but then how would you draw with that theme data? In other words, if
> the original button code in Windows is calling OpenThemeData, how can your
> subclass code ever draw using themes without opening up a second HTHEME?
>
> It would seem to me that a second HTHEME is required in this case, and
then
> I don't see how it matters if you opened it during WM_CREATE or during the
> first pass only through your paint code.

I believe you are intended to defer to the WNDCLASS implementation so it can
do the OpenThemeData and or CloseThemeData, and then use GetWindowTheme in
your subclass handler(s). Then too, I guess if you need the HTHEME of
another class (like if you want your button to look like a scrollbar), then
you just can't escape it. :)

[Jonathan Wood]

Jeff,

> I believe you are intended to defer to the WNDCLASS implementation so it
can
> do the OpenThemeData and or CloseThemeData, and then use GetWindowTheme in
> your subclass handler(s). Then too, I guess if you need the HTHEME of
> another class (like if you want your button to look like a scrollbar),
then
> you just can't escape it. :)

Doh! That's what I was missing: that GetWindowTheme returns the hTheme
(opened using OpenThemeData) of the underlying control code.

That's definitely a good nugget of information to be aware of. Thanks!

[Jonathan Wood]

Doug,

> The Visual Styles documentation is among the worst in MSDN. It was
horribly
> incomplete and ambiguous when it first came out, and reviewing it now, it
> seems not to have improved much. For my purposes, IsAppThemed() has worked
> reliably to determine if controls should be themed, but then again, I
don't
> have any controls that have disabled themes with SetWindowTheme, and as
> mentioned earlier, I'm not concerned with apps that may not have a
manifest.

I'll second your comments about the documentation for all this. If it makes
you feel any better, I was experimenting earlier with changing themes via
the Display Properties dialog. Changing themes causes many problems from
buttons (ones that I had nothing to do with) not updating, to some colors
changing (such as menu item backgrounds going white when the menu bar was
gray).

Some indication that even MS had trouble figuring it out.

[Jonathan Wood]

Jeff,

> I believe you are intended to defer to the WNDCLASS implementation so it
can
> do the OpenThemeData and or CloseThemeData, and then use GetWindowTheme in
> your subclass handler(s). Then too, I guess if you need the HTHEME of
> another class (like if you want your button to look like a scrollbar),
then
> you just can't escape it. :)

Out of curiosity, I reworked my code to call GetWindowTheme at the start of
my paint routine in a class that subclasses a button. Sure enough, it does
appear to work just fine!

I'm a little unsure if that is the best possible approach but, if it works,
it seems like it may be slightly more efficient.

[Jeff Partch]

"Doug Harrison [MVP]" <d...@mvps.org> wrote in message

news:a257p0tq72dse8d8p...@4ax.com...

> Jeff Partch [MVP] wrote:
> >Neither concerns itself with whether this particular app has a manifest
and
> >is supposed to use themes and neither is particularly determinate as to
> >whether this particular control is supposed to use themes -- only that it
> >*could* -- not not that it *should*. That leaves the similarly flawed
> >GetThemeAppProperties, and GetWindowTheme which I discuss below.
>
> I'm with you so far. ISTR a problem with IsThemeActive, causing me to use
> IsAppThemed, which has been reliable for me in apps known to have a
> manifest.

Just to let you know I recognize that you say later that you don't care
about the no manifest case, or the removed themes via SetWindowTheme, but
these are real concens in general aren't they?

> >cases. And IIRC, there are folks doing things with the activation context
to
> >disable theming after the fact even in an otherwise themed app with a
> >manifest.
>
> Example? I'm so not familiar with activation contexts. I guess if you were
> going for full generality, you'd have to worry about those things.

I'l try and drum up what I was remembering sometime today. I couldn't find
it in the archives this morening, and was getting no hits on google even for
things I know were there.

> >FYI, According to Dave Anderson, Microsoft Developer Support, you can't
> >really do this, Doug...
> >
> >"
> >> You should open a theme once per window... open it when the window is
> >> created and close the handle when the window is destroyed. There is a
> >limit
> >> of 64K handles per process. The bug is when this limit is reached,
> >> OpenThemeData does not return NULL.
> >"
> >
> >Even allowing an exception for WM_THEMECHANGED, you're now doing it twice
> >per window. :)
>
> Can't do what? Each OpenThemeData has a matching CloseThemeData. The
> WM_THEMECHANGED docs say:

I did and do allow that WM_THEMECHANGED has to be handled as documented. But
I think what Dave was saying is that there is a bug in the implementation
and this is the way to work around it. I've never even check whether he was
all wet about it, I was just quoting what he said do. I've done all the
things you listed too, Doug and they work for me as well. I was just
alerting you to what an MS representative said about the practice. Remember
this is how we all learned about the only UNICODE apps can use themes rule.
:)

> The Visual Styles documentation is among the worst in MSDN. It was
horribly
> incomplete and ambiguous when it first came out, and reviewing it now, it
> seems not to have improved much. For my purposes, IsAppThemed() has worked
> reliably to determine if controls should be themed, but then again, I
don't
> have any controls that have disabled themes with SetWindowTheme, and as
> mentioned earlier, I'm not concerned with apps that may not have a
manifest.
> These considerations aside, I've observed zero problems with the method
I've
> been using for 3+ years, and I've had no reports of any problems with it
for
> apps that run on Windows 9x and NT4 and later. The documentation gives no
> hint the approach shouldn't work; on the contrary, it gives examples
> indicating it should work. The test app I just wrote seems to confirm the
> approach is sound. So as long as it ain't broke... :)

I'm not blowing off all your fine arguments, Doug. It's just that I'm at
work right now and haven't the time to consider them fully to see if I even
have any counter. In a quick read through, I see nothing to disagree with
except that using an MS sample as the right way to do anything is in my
experience not wise. :)

I'll get back to this later tonight anad see if I can figure out what Dave
was really addressing and see if I can prove or disprove it.

[Jeff Partch]

"Doug Harrison [MVP]" <d...@mvps.org> wrote in message

news:a257p0tq72dse8d8p...@4ax.com...

> >cases. And IIRC, there are folks doing things with the activation context
to
> >disable theming after the fact even in an otherwise themed app with a
> >manifest.
>
> Example? I'm so not familiar with activation contexts.

Here's what I was remembering from last year, but I might have remembered it
backward...

http://groups.google.com/groups?hl=en&lr=&c2coff=1&th=7d28e54eabbf2492&rnum=7

> I guess if you were
> going for full generality, you'd have to worry about those things.

Oh, I always try to realize my controls that way -- but usually end up
compromising. :)
--
Jeff...

[Jeff Partch [MVP]]

"Doug Harrison [MVP]" <d...@mvps.org> wrote in message

news:a257p0tq72dse8d8p...@4ax.com...
> Jeff Partch [MVP] wrote:

> >FYI, According to Dave Anderson, Microsoft Developer Support, you can't
> >really do this, Doug...
> >
> >"
> >> You should open a theme once per window... open it when the window is
> >> created and close the handle when the window is destroyed. There is a
> >limit
> >> of 64K handles per process. The bug is when this limit is reached,
> >> OpenThemeData does not return NULL.
> >"
> >
> >Even allowing an exception for WM_THEMECHANGED, you're now doing it twice
> >per window. :)
>
> Can't do what? Each OpenThemeData has a matching CloseThemeData. The
> WM_THEMECHANGED docs say:

Hi, Doug!

I hope I didn't offend you yesterday. Anyway, I found the original post that
Dave Anderson replied to on Google, but his reply is mysteriously missing
from that archive. I tried to repro the failure that was reported using a
timer (the OP used a tight message blocking loop that I just couldn't abide,
so maybe that made the difference) and matched OTD/CTD calls, but it never
failed in any way that I could discern running for ~24 hours. So then I had
a go at the CCP. It is true, as Dave said, that there are a finite number of
slots in which to store open HTHEMEs (they are in fact coded indexes into
this array of 'theme object' pointers), but it is also true, as you say,
that matching pointers are just ref counted. So I'd have to conclude that
one would have to be up to something really far fetched to exhaust 64k of
slot positions (for what is a reasonably small finite number of 'theme
objects'). Forgive me?

Jeff...

[Doug Harrison [MVP]]

Jeff Partch [MVP] wrote:

>I hope I didn't offend you yesterday. Anyway, I found the original post that
>Dave Anderson replied to on Google, but his reply is mysteriously missing
>from that archive. I tried to repro the failure that was reported using a
>timer (the OP used a tight message blocking loop that I just couldn't abide,
>so maybe that made the difference) and matched OTD/CTD calls, but it never
>failed in any way that I could discern running for ~24 hours. So then I had
>a go at the CCP. It is true, as Dave said, that there are a finite number of
>slots in which to store open HTHEMEs (they are in fact coded indexes into
>this array of 'theme object' pointers), but it is also true, as you say,
>that matching pointers are just ref counted. So I'd have to conclude that
>one would have to be up to something really far fetched to exhaust 64k of
>slot positions (for what is a reasonably small finite number of 'theme
>objects'). Forgive me?

For making me delve back into the themes documentation? I'll have to think
about that. :)