libXLL (and its QuantLib usage)

[Ferdinando M. Ametrano-2]

Hi all

I've added Jen's libXLL project code to the current xlw repository, in a
branch called libXLL-branch
libXll does add support for exposing the functions also to VBA, and to
develop COM objects.
Everybody can check out the code from sourceforge using:
cvs -z3 -q update -P -d -r libXLL-branch

There are a couple of problems that need to be solved, and then I'll merge
the libXLL branch into the trunk.
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.

2) I tried to follow the guidelines on how to setup a project based on
xlw/libXLL (see "Docs/Setting up a project with libXLL.pdf" in the xlw
cvs). I tried with a COM/ATL project called QuantLibXL2. 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)
>build\DebugU/QuantLibXL2.dll : fatal error LNK1120: 1 unresolved externals
>Error executing link.exe.
>
>QuantLibXL2.dll - 2 error(s), 0 warning(s)

and I connot find SendMessageW anywhere.

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.
I attach here the QuantLibXL" code. Any help greatly appreciated


-------------

ciao -- Nando

PS the current version of QuantLibXL is in synch with QuantLib and the
libXLL branch. Also the spreadsheets do work

[Jens Thiel]

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.

[Jerome Lecomte-2]

I will look at the issue 1) this week end. I can't remember why I
commented it out.

JL

Ferdinando Ametrano wrote:

> Hi all
>
> I've added Jen's libXLL project code to the current xlw repository, in
> a branch called libXLL-branch
> libXll does add support for exposing the functions also to VBA, and to
> develop COM objects.
> Everybody can check out the code from sourceforge using:
> cvs -z3 -q update -P -d -r libXLL-branch
>
> There are a couple of problems that need to be solved, and then I'll
> merge the libXLL branch into the trunk.
> 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.
>
> 2) I tried to follow the guidelines on how to setup a project based on
> xlw/libXLL (see "Docs/Setting up a project with libXLL.pdf" in the xlw
> cvs). I tried with a COM/ATL project called QuantLibXL2. 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)
>> build\DebugU/QuantLibXL2.dll : fatal error LNK1120: 1 unresolved
>> externals
>> Error executing link.exe.
>>
>> QuantLibXL2.dll - 2 error(s), 0 warning(s)
>
> and I connot find SendMessageW anywhere.
>
> 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.
> I attach here the QuantLibXL" code. Any help greatly appreciated
>
>
> -------------
>
> ciao -- Nando
>
> PS the current version of QuantLibXL is in synch with QuantLib and the
> libXLL branch. Also the spreadsheets do wo
> rk

_____________________________________________________________________
GRAND JEU SMS : Pour gagner un NOKIA 7650, envoyez le mot IF au 61321
(prix d'un SMS + 0.35 euro). Un SMS vous dira si vous avez gagné.
Règlement : http://www.ifrance.com/_reloc/sign.sms

[Ferdinando M. Ametrano-2]

At 06:37 PM 3/6/2003 +0100, Jens Thiel wrote:
>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).
>[...] Well, I tried to explain this a few times. Still failed :-(((
Not this time. I finally got your point, and me too I would prefer the
multithread setting instead of "multithread DLL". You made me realize why 2
years ago when I was in Frankfurt to deploy a product I had to request my
collegues in Milan to send me some MSXXX.dll that was missing on the target
machine ;-)

The only problem is that I've been unable to compile cppunit (the QuantLib
unit test framework) in "multithread". I will investigate that and as soon
as I solve this problem I would switch to "multithread" from "multithread
DLL", if everybody agree


------------
ciao -- Nando