doublemax wrote: ↑Thu Sep 30, 2021 3:56 pm
And read the "README.txt" in the same directory.
Doing that would force me to change the project of "my_dll" from the "dll" sample (because that DLL uses the UNICODE versions of all of the wx Dlls, and "MyDll.dll" uses the
NON-UNICODE versions of all of the wx Dlls). I am not sure how should I change the settings in order to achieve that.
doublemax wrote: ↑Thu Sep 30, 2021 3:56 pm
And read the "README.txt" in the same directory.
Didn't help me much (for example what is the purpose of the 3 projects (vc9_my_dll, vc9_sdk_exe & vc9_wx_exe))
But it gave an idea to test the idea of statically linking "MyDll.dll". How shall I do this ? I other words
- How do I build WX so that it will create statically linked libraries ?
- How do I point my workspace to link to the statically linked libraries ?
==========================================================
More progress on the matter (or going backwards...)
It seems that it is possible that the problem exists only on Win_XP (yes, it's still there).
On Windows_7 for example I could not see any problem to LoadLibraty(MyDll.dll).
So, the first thing that came up to me was to rebuild wxWidgets with (visual studio 6 - on a virtual machine).
I was happy to see that there are still project & workspace - but not all sources compile under visual studio 6 (so, I had to leave this direction).
Looking at the errors it seems that VC_6 really can not handle the new code. So, I would consider dropping the VC_6 stuff.
I had tried another direction :
I tried to rebuild all of the wx stuff to match Win_XP.
- Go into All of the projects of WX, and set "Platform toolset" to "VisualStudio_2015 - Windows_XP (v140_xp)".
- Delete *.obj from the already built tree
- Open comandline windows (x86 & x64) and run the same command that I used before - to build wxWidgets (for example "nmake /f makefile.vc BUILD=release SHARED=1 UNICODE=0 TARGET_CPU=X64")
The result was bad - it did not change anything. Did I do this correctly ?
Thanks
zmau