Re: comctl32: initial theming tests

[Nikolay Sivov]

André Hentschel wrote:
> tests class redirection and "load"-order atm
>
> dlls/comctl32/tests/Makefile.in |    1 +
>  dlls/comctl32/tests/theming.c   |  301 +++++++++++++++++++++++++++++++++++++++
>  2 files changed, 302 insertions(+), 0 deletions(-)
>  create mode 100644 dlls/comctl32/tests/theming.c

Why not reuse this

+static const CHAR manifest[] =

from v6util.h.

Also it's better to introduce new create/delete manifest helpers in this 
header and use them.

It's better to use already defined classnames here:
---
+ struct classlist {WCHAR class[24]; BOOL todo;} listW[] = {like
---
STATUSCLASSNAMEW for example.

If the purpose of that
---
static void test_redirection(HINSTANCE hInstance, LPCWSTR clsname, BOOL 
todo)
---

is to show that message procedure moves to comctl32 after enabling themes than
testing for comctl32 classes is useless - winproc is already in this module.

I don't think it's a good choice:
---
+        pIsThemeActive = (void*)GetProcAddress(hUxtheme, "IsThemeActive");
+        if (!pIsThemeActive || !pIsThemeActive())
---
I mean what if I don't use theming on XP but classic decorations will it return TRUE?
Not sure but maybe this class reregistration occurs anyway when v6 module is loaded (manifest specified).
Skipping like that will drop tests on native boxes that have theming disable what isn't good.

BTW. Do you plan to reregister all user32 classes on comctl32 load? How could this be done at user32 side - testing for something like IsThemeActive() while loading user32?

comctl32: initial theming tests

[Roderick Colenbrander]

> BTW. Do you plan to reregister all user32 classes on comctl32 load? How
> could this be done at user32 side - testing for something like
> IsThemeActive() while loading user32?

I have been toying with this a bit and trying to figure out how it
works. From MSDN info and info from a site which has good comctl32
info (http://www.geoffchappell.com/viewer.htm?doc=studies/windows/shell/index.htm&...)
I have a basic idea on how it works.

According to MSDN the CreateWindow call performs some filtering and
depending on whether a manifest is around to override the windowclass
of lets say a Button, it creates a themed button. You might wonder
what it does about the window class registration. The Button class is
unregistered (I'll come to that a bit later) and I think that user32
then calls comctl32 its RegisterClassNameW function (this function is
not well documented but that page I mentioned, documents it well) to
re-register the Button class. I have no idea whether it is user32
which unregisters the Button class or whether RegisterClassNameW does
it.

For sure we need tests for RegisterClassNameW IF we want to implement
our theming this way and I have a strong feeling that this is what
microsoft uses. If you search on google for RegisterClassNameW you
also notice within the first 10 results posts like
http://www.tech-archive.net/Archive/WinXP/microsoft.public.windowsxp.general...
which makes me believe it really works this way.

I don't know user32/comctl32 that well but do you have suggestions for
tests? AJ suggested GetClassInfo tests (not sure what to look for) and
window class lookup order tests.

Roderick

comctl32: initial theming tests

[André Hentschel]

Nikolay Sivov schrieb:
> Why not reuse this
>
> +static const CHAR manifest[] =
>
> from v6util.h.
>
> Also it's better to introduce new create/delete manifest helpers in this
> header and use them.
> It's better to use already defined classnames here:
> - struct classlist {WCHAR class[24]; BOOL todo;} listW[] = {like
>
> STATUSCLASSNAMEW for example.
> If the purpose of that
>
> static void test_redirection(HINSTANCE hInstance, LPCWSTR clsname, BOOL
> todo)
>
> is to show that message procedure moves to comctl32 after enabling
> themes than
> testing for comctl32 classes is useless - winproc is already in this
> module.
> I don't think it's a good choice:
> -
>    pIsThemeActive = (void*)GetProcAddress(hUxtheme, "IsThemeActive");
> -
>    if (!pIsThemeActive || !pIsThemeActive())
>
> I mean what if I don't use theming on XP but classic decorations will it
> return TRUE?
> Not sure but maybe this class reregistration occurs anyway when v6
> module is loaded (manifest specified).
> Skipping like that will drop tests on native boxes that have theming
> disable what isn't good.

First, thanks for you review!
I think i fixed all of that in try 2 (http://www.winehq.org/pipermail/wine-patches/2009-September/078869.html) and i hope i didnt introduce new traps.