Posted by
Jens Thiel on
URL: http://quantlib.414.s1.nabble.com/libXLL-and-its-QuantLib-usage-tp2428p2429.html
Hi Nando!
> 1) in XlfExcel.h Jérôme removed:
> >///////////////////
> >HINSTANCE hInst_;
> >public:
> >void DllHandle( HANDLE hDLL);
> >HINSTANCE DllHandle() const;
> >///////////////////
>
> which was needed by Jens' code in the xllExample:
> >BOOL APIENTRY DllMain( HANDLE hModule, DWORD dwReason, LPVOID)
> >{
> >if( dwReason == DLL_PROCESS_ATTACH)
> >XlfExcel::Instance().DllHandle(hModule);
> >return TRUE;
> >}
>
> I just commented out the DllHandle lines (as per Jens' suggestion), but I
> would appreciate any help to fix this.
You already fixed it ;o)
> The Debug
> configuration does compile and link, but with the "Debug Unicode"
> configuration I have the following error:
> >Linking...
> > Creating library build\DebugU/QuantLibXL2.lib and object
> > build\DebugU/QuantLibXL2.exp
> >QuantLibXL2.obj : error LNK2001: unresolved external symbol
> "public: void
> >__thiscall XlfExcel::SendMessageW(char const *)"
> >(?SendMessageW@XlfExcel@@QAEXPBD@Z)
I guess a "SendMessage" somehow gets changed py the preprocessor to
"SendMessageA" or "SendMessageW", depending on the Unicode settings. Try to
use SendMessageA directly, or #undef SendMessage.
All library functions dealing with strings usually come in two flavours ...A
for ANSI strings, ...W for wide/unicode strings. Don't forget to use the
proper macros to deal with this!!! Otherwise your VBA and COM code will fail
as soon as strings are involved.
> With all other configurations I have linking problems. I suspect
> this might
> be because of linking with incompatible libraries. QuantLib (and its
> cppunit test-suite) uses multithreaded DLL libraries. Is this the
> problem?
> I could change QuantLib settings, but I should also recompile
> cppunit. It's
> completely obscure to me the real difference between multithreaded and
> multithreaded DLL, I just happily found out the the cppunit
> choice matched the QuantLib one.
Just stick with one type. While you prefer the "multithreaded DLL" settings
(maybe for smaller executables?), I prefer the "multithreaded" setting for
less dependencies and easier deployment ( I do not have to ship the
MFC*.DLLs since the code is already linked into the executable). The "***
DLL" settings is usually the easiest on a pure developer machine, since you
are linking against the DLLs on your own machine... Have a look in your
\WINNT\System32 directory and scroll down to the MFC*.* files -- all users
of your executable will need these, too (preferable in the exact version,
which is known as DLL hell).
Well, I tried to explain this a few times. Still failed :-(((
Lets make an example. The library shipped with VC exposes a function itoa.
If you compile it with the "*** DLL" setting, the code for itoa is NOT
included in the final executable (.dll or .exe), but is instead loaded from
a DLL at runtime (which must be present on the executing machine). If you
compile it with just "multithreaded", the code for itoa IS included in your
executable, thus it can be run without the MFC* DLLs. Mixing both does not
work.
Jens.