msclrhd at googlemail.com
Mon Apr 4 07:45:36 CDT 2011
On 4 April 2011 13:08, Andrew Green <greeniekin at gmail.com> wrote:
> I hate to message you on this email. I have messaged the mailing
> lists. Though I became more confused than anything.
Can you please keep the discussions on the mailing list? Thanks.
> I would like to propose a project where comctl32 is implement
> correctly in windows for google summer of code.
> As far as i know windows uses SxS to load version 6 of comctl allowing
This is correct -- an application needs to add a manifest file to tell
it to load version 6 of the comctl32 DLL in order to get theming
support on Windows.
> It also uses windows class redirection to hijack controls
> from user32 to be themed(I don't know if it somehow uses subclassing).
This is how it is implemented in wine.
> The confusing thing on the mailing list i was told not to make a
> separate version of comctl32. Which is understandable from a code
> maintenance point of view. Though contradicts what the gsoc ideas page
> "control is overridden by a themed drawing version by subclassing.
> This is not the way it is implemented on Windows and this causes
> drawing issues and other nasty issues."
> As someone who is to be a mentor of this section. What is the goal?
> and if subclassing is the option, how is this meant to work?
There isn't a contradition.
AFAICS, the subclassing works -- the subclassed window procedure gets
The drawing issues can be seen clearly on the button controls -- if
the button changes state (enabled <-> disabled, pressed, etc.) then it
gets drawn without theming. This is because the button control in Wine
does not call WM_PAINT to do the drawing, which the themed button
Therefore, you will need to either:
1/ convince Alexandre through tests that these tests do call
WM_PAINT [*] and update the non-themed control accordingly; or
2/ implement the state tracking/logic in the themed button and have
it call WM_PAINT [*].
[*] or the correct custom drawing messages.
More information about the wine-devel