Image List tests for comctl32 v6
Hi All, I'm working on some tests to demonstrate some alpha-channel behaviour in comctl32 ImageLists. The problem is that this behaviour is only present in comctl32 v6, which of course you usually activate with an xml manifest. For the wine test suite we have a helper function, load_v6_module, that dynamically creates a manifest resource entry in the module, which seems to activate v6 behaviour. However, while this seems to activate v6 behaviour for controls, it seems not to for image lists - my tests work if I link a manifest into the test suite, but don't work via load_v6_module. Does anyone have any thoughts about what might be going on here, and what I should do with my tests? Thanks Joel
Hi Joel,
I'm working on some tests to demonstrate some alpha-channel behaviour in comctl32 ImageLists. The problem is that this behaviour is only present in comctl32 v6, which of course you usually activate with an xml manifest. For the wine test suite we have a helper function, load_v6_module, that dynamically creates a manifest resource entry in the module, which seems to activate v6 behaviour. However, while this seems to activate v6 behaviour for controls, it seems not to for image lists - my tests work if I link a manifest into the test suite, but don't work via load_v6_module.
Do you mean that the tests pass on Windows but not Wine when using load_v6_module, or that they don't pass on either platform? I used load_v6_module for some v6 imagelist tests (which may not yet be merged into Wine actually; I should probably check that and resubmit) and they worked fine. You may want to look at http://tinyurl.com/ybo28lt for instance. If the tests are working on Windows but not on Wine, the obvious reason for your tests failing would be that the required alpha channel support is not implemented. Cheers, -- Owen Rudge http://www.owenrudge.net/
Do you mean that the tests pass on Windows but not Wine when using load_v6_module, or that they don't pass on either platform? I used load_v6_module for some v6 imagelist tests (which may not yet be merged into Wine actually; I should probably check that and resubmit) and they worked fine. You may want to look at http://tinyurl.com/ybo28lt for instance.
If the tests are working on Windows but not on Wine, the obvious reason for your tests failing would be that the required alpha channel support is not implemented.
Cheers,
It sounds like I need to investigate further, but no - I'm only talking about Windows. With crosstest, load_v6_module seems not to switch to v6 with regard to image lists.
It sounds like I need to investigate further, but no - I'm only talking about Windows. With crosstest, load_v6_module seems not to switch to v6 with regard to image lists.
That's curious. What version of Windows are you using? Could you try applying my imagelist patches I linked to earlier and see if those tests work? For me at least, they all functioned correctly on both XP and Vista. -- Owen Rudge http://www.owenrudge.net/
Joel Holdsworth wrote:
Hi All,
I'm working on some tests to demonstrate some alpha-channel behaviour in comctl32 ImageLists. The problem is that this behaviour is only present in comctl32 v6, which of course you usually activate with an xml manifest. For the wine test suite we have a helper function, load_v6_module, that dynamically creates a manifest resource entry in the module, which seems to activate v6 behaviour. However, while this seems to activate v6 behaviour for controls, it seems not to for image lists - my tests work if I link a manifest into the test suite, but don't work via load_v6_module.
Does anyone have any thoughts about what might be going on here, and what I should do with my tests?
Thanks Joel
Hi, Joel. It works for precreated manifest as a separate file (not compiled in), isn't it? If so you could do a trick that I spotted here http://www.winehq.org/pipermail/wine-patches/2009-September/078869.html for a first time - here another process is created after main test binary loaded, it's created for exactly the same binary but with a manifest created first (command line parameter passed to jump to V6 tests). Hope this helps.
Nikolay Sivov schrieb:
Joel Holdsworth wrote:
Hi All,
I'm working on some tests to demonstrate some alpha-channel behaviour in comctl32 ImageLists. The problem is that this behaviour is only present in comctl32 v6, which of course you usually activate with an xml manifest. For the wine test suite we have a helper function, load_v6_module, that dynamically creates a manifest resource entry in the module, which seems to activate v6 behaviour. However, while this seems to activate v6 behaviour for controls, it seems not to for image lists - my tests work if I link a manifest into the test suite, but don't work via load_v6_module.
Does anyone have any thoughts about what might be going on here, and what I should do with my tests?
Thanks Joel Hi, Joel.
It works for precreated manifest as a separate file (not compiled in), isn't it? If so you could do a trick that I spotted here http://www.winehq.org/pipermail/wine-patches/2009-September/078869.html for a first time - here another process is created after main test binary loaded, it's created for exactly the same binary but with a manifest created first (command line parameter passed to jump to V6 tests).
Hope this helps.
Yes, you can use hat way. I needed it as i got some different behaviours between XP-SP2, XP-SP3 and win7. SP2 and win7 behaved the same, while SP3 seemed to ignore the v6utils. -- Best Regards, André Hentschel
It works for precreated manifest as a separate file (not compiled in), isn't it? If so you could do a trick that I spotted here http://www.winehq.org/pipermail/wine-patches/2009-September/078869.html for a first time - here another process is created after main test binary loaded, it's created for exactly the same binary but with a manifest created first (command line parameter passed to jump to V6 tests).
Hope this helps.
Ok... I've been looking at the child process code, and I think it's not necessary to do that (though you might be doing something more complex - I haven't looked at the patch in detail). The activation context method that's already present sets up a manifest-enabled state of affairs. The big gotcha is that you have to reload any function pointers that you might care to use... http://wine.pastebin.com/m11141e7a As you can see here my version of the test unloads comctl32, switches on the activation context, and then reloads comctl32, and then loads pointers for ALL THE FUNCTIONS THAT WILL BE NEEDED. If you then call these, you have a state of affairs that is pretty much identical to what you get with a manifest from the start.
Joel Holdsworth schrieb:
It works for precreated manifest as a separate file (not compiled in), isn't it? If so you could do a trick that I spotted here http://www.winehq.org/pipermail/wine-patches/2009-September/078869.html for a first time - here another process is created after main test binary loaded, it's created for exactly the same binary but with a manifest created first (command line parameter passed to jump to V6 tests).
Hope this helps.
Ok... I've been looking at the child process code, and I think it's not necessary to do that (though you might be doing something more complex - I haven't looked at the patch in detail). The activation context method that's already present sets up a manifest-enabled state of affairs. The big gotcha is that you have to reload any function pointers that you might care to use...
http://wine.pastebin.com/m11141e7a
As you can see here my version of the test unloads comctl32, switches on the activation context, and then reloads comctl32, and then loads pointers for ALL THE FUNCTIONS THAT WILL BE NEEDED. If you then call these, you have a state of affairs that is pretty much identical to what you get with a manifest from the start.
Wow, thats great. Thanks for the idea! I will update my code. -- Best Regards, André Hentschel
Joel Holdsworth wrote:
It works for precreated manifest as a separate file (not compiled in), isn't it? If so you could do a trick that I spotted here http://www.winehq.org/pipermail/wine-patches/2009-September/078869.html for a first time - here another process is created after main test binary loaded, it's created for exactly the same binary but with a manifest created first (command line parameter passed to jump to V6 tests).
Hope this helps.
Ok... I've been looking at the child process code, and I think it's not necessary to do that (though you might be doing something more complex - I haven't looked at the patch in detail). The activation context method that's already present sets up a manifest-enabled state of affairs. The big gotcha is that you have to reload any function pointers that you might care to use...
http://wine.pastebin.com/m11141e7a
As you can see here my version of the test unloads comctl32, switches on the activation context, and then reloads comctl32, and then loads pointers for ALL THE FUNCTIONS THAT WILL BE NEEDED. If you then call these, you have a state of affairs that is pretty much identical to what you get with a manifest from the start.
That's interesting. If it works for window classes too we should use it for ListView and Header tests too cause these are failing now on XP SP3 for some reason (but work fine on up to Win7).
Joel Holdsworth schrieb:
It works for precreated manifest as a separate file (not compiled in), isn't it? If so you could do a trick that I spotted here http://www.winehq.org/pipermail/wine-patches/2009-September/078869.html for a first time - here another process is created after main test binary loaded, it's created for exactly the same binary but with a manifest created first (command line parameter passed to jump to V6 tests).
Hope this helps.
Ok... I've been looking at the child process code, and I think it's not necessary to do that (though you might be doing something more complex - I haven't looked at the patch in detail). The activation context method that's already present sets up a manifest-enabled state of affairs. The big gotcha is that you have to reload any function pointers that you might care to use...
http://wine.pastebin.com/m11141e7a
As you can see here my version of the test unloads comctl32, switches on the activation context, and then reloads comctl32, and then loads pointers for ALL THE FUNCTIONS THAT WILL BE NEEDED. If you then call these, you have a state of affairs that is pretty much identical to what you get with a manifest from the start.
Just tried it and it doesnt work for my tests, but i dont use GetProcAddress with any function from comctl32. So i think in your tests its the best solution, but i have to use the childprocess-way. -- Best Regards, André Hentschel
On Fri, 2009-10-02 at 02:40 +0400, Nikolay Sivov wrote:
Joel Holdsworth wrote:
Hi All,
I'm working on some tests to demonstrate some alpha-channel behaviour in comctl32 ImageLists. The problem is that this behaviour is only present in comctl32 v6, which of course you usually activate with an xml manifest. For the wine test suite we have a helper function, load_v6_module, that dynamically creates a manifest resource entry in the module, which seems to activate v6 behaviour. However, while this seems to activate v6 behaviour for controls, it seems not to for image lists - my tests work if I link a manifest into the test suite, but don't work via load_v6_module.
Does anyone have any thoughts about what might be going on here, and what I should do with my tests?
Thanks Joel
Hi, Joel.
It works for precreated manifest as a separate file (not compiled in), isn't it? If so you could do a trick that I spotted here http://www.winehq.org/pipermail/wine-patches/2009-September/078869.html for a first time - here another process is created after main test binary loaded, it's created for exactly the same binary but with a manifest created first (command line parameter passed to jump to V6 tests).
Hope this helps.
Yes that looks like what I need. Have you had any luck getting your patch merged? - I'd happily build on your work.
Joel Holdsworth wrote:
On Fri, 2009-10-02 at 02:40 +0400, Nikolay Sivov wrote:
Hi, Joel. It works for precreated manifest as a separate file (not compiled in), isn't it? If so you could do a trick that I spotted here http://www.winehq.org/pipermail/wine-patches/2009-September/078869.html for a first time - here another process is created after main test binary loaded, it's created for exactly the same binary but with a manifest created first (command line parameter passed to jump to V6 tests).
Hope this helps.
Yes that looks like what I need. Have you had any luck getting your patch merged? - I'd happily build on your work.
It's not mine actually. I think it isn't merged cause of main part, not manifest enabling code.
On 02.10.2009 00:27, Joel Holdsworth wrote:
Does anyone have any thoughts about what might be going on here, and what I should do with my tests?
If the manifest is set up dynamically I would expect that all symbols imported from comctl32.dll are done so _before_ the manifest takes effect, ie any comctl32 functions would be from the pre-v6 one chosen at the program load time. (Apparently, for window classes, there is some extra mechanism in Windows that makes the v6 classes used.) If that is the case the solution would probably be to load v6 comctl32.dll dynamically and obtain the symbols you want to use at runtime as well. -f.r.
Frank Richter wrote:
On 02.10.2009 00:27, Joel Holdsworth wrote:
Does anyone have any thoughts about what might be going on here, and what I should do with my tests?
If the manifest is set up dynamically I would expect that all symbols imported from comctl32.dll are done so _before_ the manifest takes effect, ie any comctl32 functions would be from the pre-v6 one chosen at the program load time. (Apparently, for window classes, there is some extra mechanism in Windows that makes the v6 classes used.)
After it loaded GetModuleHandle() won't return a correct value, if I'm right, there's a special case for SxS.
If that is the case the solution would probably be to load v6 comctl32.dll dynamically and obtain the symbols you want to use at runtime as well.
-f.r.
How, with full path? It isn't good either.
On Fri, Oct 2, 2009 at 6:49 PM, Nikolay Sivov <bunglehead(a)gmail.com> wrote:
Frank Richter wrote:
On 02.10.2009 00:27, Joel Holdsworth wrote:
Does anyone have any thoughts about what might be going on here, and what I should do with my tests?
If the manifest is set up dynamically I would expect that all symbols imported from comctl32.dll are done so _before_ the manifest takes effect, ie any comctl32 functions would be from the pre-v6 one chosen at the program load time. (Apparently, for window classes, there is some extra mechanism in Windows that makes the v6 classes used.)
After it loaded GetModuleHandle() won't return a correct value, if I'm right, there's a special case for SxS.
If that is the case the solution would probably be to load v6 comctl32.dll dynamically and obtain the symbols you want to use at runtime as well.
-f.r.
How, with full path? It isn't good either.
Together with Andre I have been working on some comctl32 v6 tests. I also tried to dynamically apply a manifest to figure at what point windows classes are re-registered. Calling CreateWindow after applying a manifest doesn't appear to work (at least on XP SP3). I'm not sure what happens to function calls after a context switch (when switching to the manifest). Perhaps it is important to load the functions dynamically then, I believe InitCommonControlsEx is important in some cases, perhaps try to call it. Roderick
participants (6)
-
André Hentschel -
Frank Richter -
Joel Holdsworth -
Nikolay Sivov -
Owen Rudge -
Roderick Colenbrander