0

I am very new to C-plus-plus and trying to use it to create user-defined functions for excel. I wrote a very simple test function in Cpp that just adds two arguments together (Excel cell references).

I compiled a 32-bit DLL & a seperate 64-bit DLL project using the same *.cpp and *.def files in Visual Studio 2013.

When I run the 32-bit DLL on a 32-bit Excel install, the new excel function works fine (eg: 5 + 10 = 15).

When I run the 64-bit DLL on a 64-bit Excel install, I am getting a #VALUE error in the cell.

Can anyone see something blatantly wrong that I am doing with the 64-bit DLL? Thanks!

***** VBA (32-bit) *****
Declare Function ExPlus Lib _
"C:\AKH-VSWS\Ex-Plus32\Debug\Ex-Plus32.dll" _
(ByVal a As Double, _
 ByVal b As Double) As Double

Computer 1: Windows 7 (64-bit), Office 2016 (32-bit), Visual Studio 2013

***** VBA (64-bit) *****
Declare PtrSafe Function ExPlus Lib _
"C:\AKH-VSWS\Ex-Plus64\x64\Debug\Ex-Plus64.dll" _
(ByVal a As Double, _
 ByVal b As Double) As Double

Computer 2: Windows 7 (64-bit), Office 2016 (64-bit)

Microsoft (R) COFF/PE Dumper Version 12.00.21005.1
Copyright (C) Microsoft Corporation.  All rights reserved.

Dump of file c:\AKH-VSWS\Ex-Plus64\x64\Debug\Ex-Plus64.dll
PE signature found
File Type: DLL

FILE HEADER VALUES
            8664 machine (x64)
               7 number of sections
        5AC930F1 time date stamp Sat Apr 07 16:58:25 2018
               0 file pointer to symbol table
               0 number of symbols
              F0 size of optional header
            2022 characteristics
                   Executable
                   Application can handle large (>2GB) addresses
                   DLL
Community
  • 1
  • 1
justhumm
  • 11
  • 2
  • You cannot use C++ to build a DLL file that exports COM types or C-style functions and have it work in both a 32-bit and 64-bit environment. – ashleedawg Apr 08 '18 at 03:45
  • Possible duplicate of [Creating C++ .dll for use by Excel & C# (32/64bit Window)](https://stackoverflow.com/questions/15309846/creating-c-dll-for-use-by-excel-c-sharp-32-64bit-window) – ashleedawg Apr 08 '18 at 03:46
  • @ashleedawg, if I am reading your comment correctly, you are correct. DLL's won't work in voth worlds. I have two seperate VStudio projects. 1 to compile a 32bit DLL. And 1 to compile a seperate 64bit DLL. The 32bit's working as expected, but the 64bit function is returning errors in Excel. I can't figure out if its a compiler error or a VBA error...Suggestions? Where/how to start debugging? – justhumm Apr 08 '18 at 13:08

3 Answers3

0

This isn't a solution, but it might be a step in the right direction...I happened to stumble over a page today. And the recommended software seems to think that my DLL can not find a dependency (MSVCR120D.DLL). So I'll need to look into this more.

...still open to suggestions, though...

http://access.mvps.org/access/bugs/bugs0019.htm

This is caused by a missing Dependency file (runtime files) on your machine that's required by the DLL. The error message "File Not Found" is not being generated by the DLL file itself, but Access since it cannot locate the other required DLLs.

To find out if the DLL has any dependencies, you can use one of these two methods...Download Dependency Walker Search your hard drive for any dependent files and make sure they exist and are registered.

Dependency Walker screenshot

justhumm
  • 11
  • 2
0

The plot thickens...

It appears that I have compiled in "debug" mode, and might have to change the Visual Studio setting from "debug" to something else.

VS2012 MSVCR120D.dll is missing

"...the "D" stands for debug information...The debug DLLs come only with the respective version of Visual Studio and are not meant to be redistributed..."

justhumm
  • 11
  • 2
0

I think I figured out what my issues were...

I was compiling it in debugger mode, so it was adding a "D" onto the name of one of the dependency files. And when I moved the DLL to a computer without Visual Studio, it wouldn't run. I had to switch my compile settings to release mode.

In the *.cpp file, I was missing one of the two underscores (_) in the __stdcall statement. And Visual Studio's debugger and I weren't catching it. So the user-defined-function wasn't being exported with the DLL.

I also didn't properly register / set-up the *.def file within Visual Studio. So even if the __stdcall statement was correct, the function still wouldn't have exported correctly.

And apparently, if you don't somehow register the UDF with excel/windows, you need to run the C++/DLL function through a local VBA function. I have to read up on that (XLL's and all that fun stuff).

So, in conclusion, yeah...I was being stupid.

justhumm
  • 11
  • 2