Theming widgets

[Kevin Koltzau]

I'm starting to work on theming some widgets, and I've come up with a few methods of doing this:
1) Add theming code to every widget itself, static link to uxtheme.dll
2) Add theming code to every widget itself, using LoadLibrary/GetProcAddress
3) Subclass widgets when uxtheme.dll is loaded and override default painting

Windows takes a totally different approach, using a different version of common controls that implement
theming, under windows in order to enable theming you first need a manifest to load the proper version of comctrl32
then you also must call InitCommonControls which registers the standard controls (BUTTON,EDIT,etc)

Going with that, I think #3 might be the best option, and extend InitCommonControls to subclass the standard
controls if theming is enabled

Any comments/suggestions?

[Mike Hearn]

On Tue, 24 Feb 2004 22:04:13 -0500, Kevin Koltzau wrote:
> I'm starting to work on theming some widgets, and I've come up with a few methods of doing this:
> - Add theming code to every widget itself, static link to uxtheme.dll
> - Add theming code to every widget itself, using LoadLibrary/GetProcAddress
> - Subclass widgets when uxtheme.dll is loaded and override default painting

4) Theme all widgets with a hard link to uxtheme but have a "Win98 look"
theme which replicates the current drawing?
> Windows takes a totally different approach, using a different version of
> common controls that implement theming, under windows in order to enable
> theming you first need a manifest to load the proper version of
> comctrl32 then you also must call InitCommonControls which registers the
> standard controls (BUTTON,EDIT,etc)

Well, to be strictly like Windows then I guess we could actually build
comctl32 twice with #ifdefs etc for the theming code.
> Going with that, I think #3 might be the best option, and extend
> InitCommonControls to subclass the standard controls if theming is
> enabled

That sounds rather complicated and like it might introduce further bugs
when apps don't expect controls to be already subclassed...

thanks -mike

[Kevin Koltzau]

On Wednesday 25 February 2004 06:28 am, Mike Hearn wrote:
> - Theme all widgets with a hard link to uxtheme but have a "Win98 look"
>
> theme which replicates the current drawing?

This actually would end up happening in all cases, if theming is disabled the widget is responsible for drawing
itself, if theming is enabled then uxtheme handles it..so basically the current drawing system will be kept in place
and an extra path added for the themed case
> Well, to be strictly like Windows then I guess we could actually build
> comctl32 twice with #ifdefs etc for the theming code.

Unfortunately in order to make that work properly, we would need to implement quite a bit of
the Side-by-side Assembly system and the Activation Context API...
Tho it may be possible to do with a hack to just handle loading the alternate comctl when there is a manifest
indicating that
> > Going with that, I think #3 might be the best option, and extend
> > InitCommonControls to subclass the standard controls if theming is
> > enabled
>
> That sounds rather complicated and like it might introduce further bugs
> when apps don't expect controls to be already subclassed...

I don't think subclassing a standard control as the class level would be detectable to applications..
this is, AFAIK, how Stardoc Windowblinds works