On 4 April 2011 13:08, Andrew Green greeniekin@gmail.com wrote:
Hi, 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 theming.
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 says "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 called correctly.
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 overrides.
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.
HTH, - Reece
On 4/4/2011 16:45, Reece Dunn wrote:
On 4 April 2011 13:08, Andrew Greengreeniekin@gmail.com wrote:
Hi, 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 theming.
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.
Native doesn't subclass, it has its own copy of so called builtin controls in comctl32. First evidence for that is a special class registration call from comctl32 v6 to register themed classes. Second evidence is that new Button functionality for example is available only in comctl32 v6, not in latest user32 module, I doubt they customize existing behaviour, I think it's more likely some message handlers are reused (compiled in both modules) and some are present in comctl32 only.
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 says "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 called correctly.
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 overrides.
Subclass may work fine of course, but could cause problems. For example it's possible that application clears all subclass slots (if we're talking about comctl32 mechanism with procedure stack). When you create button with v6 on windows you don't get sublcassed control (stack is empty), that may be important.
Anyway if you subclass let's say a Button you need to override lot of handlers potentially, cause for example new window styles could be rejected by modern user32 but accepted in comctl32 logic. That could cause a mess when different code works with not necessary valid control data. This needs some testing.
Another question is to determine if we need to use controls from comctl32 in a first place. If you have active theme it doesn't mean that developer wanted to use it if he doesn't specify manifest to load version 6.
So to summarize, the way I see this to be properly done step by step:
1) add class redirect detection for activation context code (ntdll/kernel32). Returned structures are undocumented, but if you dump data you'll see something (I did); 2) (hard part, for me at least) figure out when to invoke class registration call from comctl32 to move registration to comctl32. 3) add tests for user32 to see how builtin classes respond to new version 6 styles/messages; 4) figure out what code could be reused between user32 and comctl32 and reuse as much handlers from user32 as possible. This will need some build tweaks probably, I'm not sure, to share files between dlls.
What also bothers me is that I'm not sure comctl32 versions of controls (in windows) use A/W magic for procedures that user32 uses.
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.
HTH,
- Reece
Thank you so much for your assistance and patience.
The thing that confuses me is you want only one dll for comctl32
Though the only way i can think of to do this is to to have an xml parser inside the dll and then trying to load the correct manifest file. To check if the manifest exists or asks for version 6+. There may be some api for this. Though I havn't been able to find it.
At this link in the Window Class section I assume is what you referred to about the comctl32 having a manifest in our previous discussions. So i'm trying to get my head around that. http://msdn.microsoft.com/en-us/library/aa374219(v=vs.85).aspx
On Mon, Apr 4, 2011 at 11:19 PM, Nikolay Sivov bunglehead@gmail.com wrote:
On 4/4/2011 16:45, Reece Dunn wrote:
On 4 April 2011 13:08, Andrew Greengreeniekin@gmail.com wrote:
Hi, 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 theming.
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.
Native doesn't subclass, it has its own copy of so called builtin controls in comctl32. First evidence for that is a special class registration call from comctl32 v6 to register themed classes. Second evidence is that new Button functionality for example is available only in comctl32 v6, not in latest user32 module, I doubt they customize existing behaviour, I think it's more likely some message handlers are reused (compiled in both modules) and some are present in comctl32 only.
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 says "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 called correctly.
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 overrides.
Subclass may work fine of course, but could cause problems. For example it's possible that application clears all subclass slots (if we're talking about comctl32 mechanism with procedure stack). When you create button with v6 on windows you don't get sublcassed control (stack is empty), that may be important.
Anyway if you subclass let's say a Button you need to override lot of handlers potentially, cause for example new window styles could be rejected by modern user32 but accepted in comctl32 logic. That could cause a mess when different code works with not necessary valid control data. This needs some testing.
Another question is to determine if we need to use controls from comctl32 in a first place. If you have active theme it doesn't mean that developer wanted to use it if he doesn't specify manifest to load version 6.
So to summarize, the way I see this to be properly done step by step:
- add class redirect detection for activation context code
(ntdll/kernel32). Returned structures are undocumented, but if you dump data you'll see something (I did); 2) (hard part, for me at least) figure out when to invoke class registration call from comctl32 to move registration to comctl32. 3) add tests for user32 to see how builtin classes respond to new version 6 styles/messages; 4) figure out what code could be reused between user32 and comctl32 and reuse as much handlers from user32 as possible. This will need some build tweaks probably, I'm not sure, to share files between dlls.
What also bothers me is that I'm not sure comctl32 versions of controls (in windows) use A/W magic for procedures that user32 uses.
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.
HTH,
- Reece
-
Andrew Green -
Nikolay Sivov -
Reece Dunn