On 12/15/2009 15:52, Roderick Colenbrander wrote:
Great that you got it working. Regarding actctx, this should work fine with our manifest support. Not much has to happen at all. Basically in user32 it needs to be checked whether a window class (lets say the Button one) is redirected or not. If it is redirected at dll init, just call RegisterClassNameW.
Yesterday I started with it, you may find current helper in attached patch. It doesn't work yet, the only thing I finished is to find a context and module name that redirects specified class, that part works ok with some problems in existing context code: --- /* query_index.ulAssemblyIndex = key_data.ulAssemblyRosterIndex; */ --- at this point returned index doesn't pass parameter validation in next QueryActCtxW() call, but it's not a stopper for now and I forced it to 1 (2 was returned).
The main problem is that I still can't get module handle to this SxS library. It's even worse, testing on Windows I'm not able to GetModuleHandle() for this library with full path explicitly hardcoded. It's a bit strange.
After some testing on Windows I found that DllMain for mine library is called only after attempt to CreateWindow() with redirectable classname and the following sequence produced: --- DLL_PROCESS_ATTACH call to RegisterClassNameW DLL_PROCESS_DETACH /* disregarding that return value from registration call was success or not */ --- That's all done during CreateWindow() call.
I'd like to see some comments from kernel-knowledge developers - is it ok that SxS module load is delayed and how properly replicate this outside kernel32 (inside user32 for this case).
Thanks.
The only thing I'm still interested in is whether Microsoft really isn't subclassing the controls as I think Microsoft might have added those calls because of theming. It would be trivial to call GetWindowSubclass on a comctl32 v6 button.
True, this could be easily tested, but it's next part of the problem, first of load I need to register classes.
Roderick