::GetModuleHandle("comctl32.dll") returns 0 when executed from a dll calling wxWidgets code on windows 7 #14474
Issue migrated from trac ticket # 14474
component: wxMSW | priority: high | resolution: invalid
2012-07-10 02:10:37: jgmdev (Jefferson) created the issue
Using the wxDatePickerCtrl using the wxPHP binding fails on windows 7, After doing some testing the culprit is ::GetModuleHandle("comctl32.dll"). This function is returning 0 on windows 7 when executed on a dll with wxWidgets code loaded by another executable which is the case of wxPHP.
php.exe loads php_wxwidgets.dll and this dll makes calls to wxWidgets class methods.
Here is the code that blocks wxDatePickerCtrl (msw\datecontrols.cpp) if comctl32 version is to old:
if ( wxApp::GetComCtl32Version() < 470 )
GetComCtl32Version() tries to get the handle of already loaded comctl32.dll to get its version, but it fails by returning 0 if code is executed inside a dll on windows 7.
Works well on windows xp with same code but not on windows 7 and it seems is the same problem reported here:
I have applied the patch provided on mentioned previous ticket and now it works without an issue. I have adapted the patch for current wxwidgets trunk.
Also I tested the python wxDatePickerCtrl on win 7 but it is using generic one instead of native, maybe because of this issue.
The text was updated successfully, but these errors were encountered:
2012-07-10 02:30:32: jgmdev (Jefferson) commented
Applying this patch also fixed a strange behavior on wxListCtrl when displayed with multiple columns. A row would not be selected by clicking on a column that it isn't the first one. Also clicking on the first column only selected the first column of the row and not the whole row.
Behavior also present on windows 7
2012-07-10 10:21:01: @aasselin-en commented
You should definitely not use this patch, your problem is that your messing with Side by Side activation. If you use those functions you are going to get the handle for an unexpected version of comctl32.dll
You need to read Side by Side "activation context" stuff. The reason for all that 'mess' is that you expect to get 6.0 common controls whereas the default is (lower number don't remember exactly). Thus Windows refuses to tell "control32.dll version 6 is here". Windows is right this is not a bug.
see documentation in MSDN:
2012-07-10 17:46:18: @vadz changed status from new to closed
2012-07-10 17:46:18: @vadz set resolution to invalid
2012-07-10 17:46:18: @vadz commented
Yes, comment:2 is completely correct. You should either ensure that the main application uses a proper manifest or build with
This patch is not the right fix.
2012-07-11 03:45:09: jgmdev (Jefferson) commented
Replying to [comment:3 vadz]:
Compiling the php_wxwidgets.dll with ISOLATION_AWARE_ENABLED defined didn't solved the problem, even including another manifest file as '2 24 "manifest_file"' doesn't worked. I'm not getting 6.0 controls on wxphp applications either.
It seems I jumped a step on the report of how php works on windows:
php-win.exe -> php5.dll -> php_wxwidgets.dll
I guess it is the same way as python, but I have run out of ideas.
2012-07-11 03:50:18: jgmdev (Jefferson) commented
Replying to [comment:2 aasselin]:
So what you are saying is that I need to use one of those activation functions on the php_wxwidgets.dll in order for it to work normally?
In any case php works like the following:
php-win.exe -> php5.dll -> php_wxwidgets.dll
I'm still not sure what to do
2012-07-12 10:41:36: @aasselin-en commented
using ISOLATION_AWARE_ENABLED while building wxwidgets will place an activation aware stub (which activates the manifest of the dll the particular code is linked into) around most functions such as CreateWindow, LoadLibrary and so on which actually care about the version of common controls.
note that the manifest of the DLL is respected inside the LoadLibrary call loading it, but that's the only moment when it is naturally used, else you need your own call to activation context API or ISOLATION_AWARE_ENABLED flag when building wx dll (as this wx code which actually call CreateWindowEx).
to verify that the right manifest is well loaded by ISOLATION_AWARE_ENABLED enabled function, search for it in the .h and place breakpoints in these functions, it is probable that the manifest is not loaded, has some error or whatsoever... or some other function code takes place in between and activate yet another bad context.
hope it helps, Armel