EXTERNALEXCEPTION in simple dll call

Gareth Owen · Post by **Gareth Owen** » Thu Jan 19, 2006 6:31 am

I am having trouble getting IA to call a simple DLL.

The DLL has a single entry point

fnTest

and takes 2 arguments
TESTDLL_API long fnTest(TCHAR* text, long random)

It returns the second input argument.

If I call this from IA using the command

~InstallAware Clipboard Data~
~Call DLL Function~
~{A50FBE6A-1E02-46E4-8676-0A378DD824CE}~
~testdll.dll,fnTest,long,OUTPUTNUMBER,"pointer to string",$INPUTSTRING$,long,$INPUTNUMBER$,$~
~~mIDEFunc.dll\\mEXEFunc.dll~~
~Set Variable~
~{42B6993E-CFD8-4548-8FA5-D90E995FD2EE}~
~INPUTSTRING~
~Hello World~
~Set Variable~
~{A993EAAD-251C-4F54-98CB-65A6F3F2D4C9}~
~OUTPUTNUMBER~
~0000~
~Set Variable~
~{15FAC04D-90D8-4666-8F4F-909491B43ABB}~
~INPUTNUMBER~
~1234~

The output number just gets set to EXTERNALEXCEPTION

Any Ideas?

I have attached the DLL source.

File Attached:

testdll.rar

MichaelNesmith · Post by **MichaelNesmith** » Thu Jan 19, 2006 7:49 am

As described in the help file for the Call DLL Function plug-in, it would seem the exception handler InstallAware is using to protect the DLL call is catching an exception that occurs in your DLL. I am sorry but I am not well versed in C/C++ so I cannot help you with the DLL in particular. It could be any number of things including DLL code, DLL dependencies, and so on.

Gareth Owen · Post by **Gareth Owen** » Thu Jan 19, 2006 8:15 am

DLL works fine when called from other applications.
This one does absolutely nothing, just returning the input value, so there should be now issues there.

I have had a go at debugging the DLL, the values comming into it are correct, and the return value is ok as it is about to leave the DLL.

There is definately an issue somewhere between the DLL return value and what IA is getting, but it is not something I can debug.

Please Help

MichaelNesmith · Post by **MichaelNesmith** » Thu Jan 19, 2006 12:02 pm

I really wish I could do more - unfortunately my own knowledge of this issue is limited so I am unable to help. I am hoping some of our MVPs will look into this for you...

stevew · Post by **stevew** » Thu Jan 19, 2006 11:22 pm

hi,

I have looked at this code sample and tested with 5.0, not the latest. I believe this is what we in the industry call an issue with InstallAWARE.

The dll can't return a value.

To work around this another way you can just return the function value as a parameter. For example:

TESTDLL_API void fnTest(TCHAR* text, long *numb)
{
MessageBox(0, text, "DEBUG", MB_OK);
*numb = 5;
return;
}

Then in InstallAWARE you can define the second param as "pointer to long".

Do i get to be MVP yet? What is that good for? Free updates? Tea with Sinan?

Gareth Owen · Post by **Gareth Owen** » Fri Jan 20, 2006 2:24 am

Ah ha, Thanks, much appreciated.

And you have my vote

CandiceJones · Post by **CandiceJones** » Mon Jan 23, 2006 11:48 am

Hi!

As far as we know, there are no issues with return values in DLLs. However if you are having problems with return values, it may seem that parameter passing and calling conventions might be wrongly declared - just a guess. WinAPI calls all use return values and these work correctly with Call DLL Function.

Steve, Sinan thanks you very much for helping out Gareth here, and wants me to tell you you are well on your way to being initiated into the mysterious circle of InstallAware MVPs with its secret benefits

Gareth Owen · Post by **Gareth Owen** » Mon Jan 23, 2006 12:02 pm

Is it possible for someone to send a working version of the DLL source code and the IA script?

I have managed to work arround the issue using the method suggested by stevew, but I would be very interested to see exactly what calling convention should be used to get the return value working.

It might be required in the future

CandiceJones · Post by **CandiceJones** » Mon Jan 23, 2006 12:33 pm

Yes, please email them to Michael, we'll see what we can dig up here for you.

stevew · Post by **stevew** » Mon Jan 23, 2006 1:30 pm

also, regarding my mention of an issue. i suspect that the most probable problem is just a missing line in the help file ... not an actual software change.

I did my test compiling __cdecl. If there is not problem calling normal win32 API then likely this is because normal win32 API are compiled as __stdcall. Compiling any custom dll as __stdcall should allow the function to return from the DLL.

Just a guess. I did notice that Gareth's sample was written in something like version 2003. I am not as fluent in this version, only 6.0. I am not sure where this setting is in version 2003.

CandiceJones · Post by **CandiceJones** » Mon Jan 23, 2006 1:48 pm

Exactly. The calling conventions need to be stdcall. I reviewed the help file entry for this command and this is the first line:

Call DLL Function

This plug-in provided command calls a function exported from a DLL. The function must be available under the specified function name and use the __stdcall calling convention.

stevew · Post by **stevew** » Mon Jan 23, 2006 5:25 pm

boing. forgot to read the help file before laying blame. shame on me. should always be first step.

Gareth Owen · Post by **Gareth Owen** » Tue Jan 24, 2006 6:50 am

Ah!, ok, finally got the return working.

Never been much good at C.

Thanks for the help people

Ryan Lee · Post by **Ryan Lee** » Tue Jul 10, 2007 4:15 pm

I was wondering if you could post an example of your solution. I have the same problem but could not figure it out yet.

Thanks,
Ryan

Ryan Lee · Post by **Ryan Lee** » Tue Jul 10, 2007 6:29 pm

Never mind, I figured it out.

For the benefit of others here's how I did it using Microsoft Visual Studio 2005.

Header file - declare the function--------
extern "C" {bool __stdcall MyFunc(TCHAR* inputString);}

Source file - implementation--------
bool __stdcall MyFunc(TCHAR* inputString)
{
... do something
return true;
}

Defintion file - input this by specifying it in the linker input settings for the project--------
EXPORTS
MyFunc=_MyFunc<input>