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