Add in doesn't work on other pc

[Guest]

Hi! I made an add in for excel 2000 on my pc. In the add in I'm using or
simply declaring functions inside a DLL using VBA. The DLL and add in work
just fine on my own computer but when I try to use them on another similar
system(excel 2000) the add in stops working and shows the error report
"#VALUE!" for every result on any function. Is there something I am missing
or is it possible to distribute this kind of add in to other pcs? Thank you
for any comments regarding my problem!

-Janne Ervasti

 

[Guest]

did you distribute the DLL and register it on that machine with Regsvr32?

 

[Guest]

Hey Tom,

Thank you for your quick answer! I have distributed the DLL as well on the
other PC's system32 folder. I also tried putting it into another folder and
including its path in the VBA code but it wouldn't work.

Does the DLL really need to be registered on the other computer if it's only
a plain basic DLL that I made with VC++ and includes only the functions I
need plus the Dllmain entry point? Isn't this only the case with ActiveX DLLs
and such? My DLL doesn't even include the function srvreg32 is looking for
when registering.

I tried to register my DLL with the srvreg32 but for some reason it
complains about not finding the dll eventhough I include the whole path in
the command.

Best Regards,
Janne Ervasti

 

[NickHK]

If this was created in in VC++, which calling convention is used.
VB/VBA only supports __stdcall not __cdecl.
http://www.codeproject.com/dll/dll_calling.asp

Show a sample of you Declares.

NickHK

 

[NickHK]

Ignore the bit about calling convention, as I missed the bit that you had it
working on your PC.
However, post a couple of Declares.

NickHK
P.S. I have seen this if your DLL has a/some dependencies missing and
consequently can't load.
Check that all the files your DLL requires are present on the new PC.

 

[Guest]

Hello Nick!

In the code for my DLL functions are declared with:

extern "C" int __stdcall function1(int variable1)
{
//code...
}

After this I have included it in my .def file with:

LIBRARY "functions"
EXPORTS
function1 @1

Then I built the DLL and wrote the following in VBA:

Option Explicit

Public Declare Function my_function Lib "functions.dll" Alias "function1" _
(ByVal var1 As Integer) As Integer

After which I saved the workbook containing my module of code with the
function declarations as an .xla add in file.

Once doing this I distributed the add in and DLL to another PC but I am not
able to get the same correct behaviour there as on my own PC.

-Janne Ervasti

 

[NickHK]

I'm no expert on this stuff, but AFAIK, a C int is a VB Long.
But if it works on your PC then I doubt that is problem, but you may not get
your expect numbers back in VBA.
I'd say it would be trouble with the path and/or dependencies.

NickHK

 

[Guest]

Hey Nick,

I tried exporting the whole project directory of my DLL from my own PC and
including the path to the DLL in there in the VBA on another PC but still got
no better results. I couldn't think of any other reasonable way of exporting
all of the libraries I used when making the DLL but please tell me if there
was some other way you were thinking.

The declarations I wrote earlier are the formulas for all of the functions I
have declared in both VC++ and VBA. All of the functions give the same error
result in Excel once they are called.

Best Regards,
Janne Ervasti

 

[Guest]

Yes, you are right. The int was supposed to be a 16-bit unsigned short int.

-Janne

 

[Guest]

Hello,

finally I got it working on other PCs. The problem doesn't seem to be in the
code but it seems more like a problem the development environment or the
settings of the development environment. When I first built the DLL I made in
Visual Studio 2005 and .NET framework version 2.0.5.0727(running on Windows
2000 with Excel 2000). These DLLs would not work on other PCs. After this we
tried developing corresponding DLL on other system setups. Building the DLL
on an older version of VC++ which was on Visual Studio 2003 seemed to produce
DLL files that were bigger in size and also worked on other PCs and at least
on Excel 2000 and 2003. The problem seems to be the interface the DLL is
providing for Excel to call. Maybe different .NET environments give different
results on the final DLLs. Still I don't know the exact reason for why my own
PCs DLL would not work on other PCs but for now I would blame it on the new
..NET. If anybody has any idea please let me know.

BR,
Janne