Simple Windows DLL problem?

[martes]

I want to create a Windows DLL that I can access the exported function via VBA.

I went to create a Windows DLL, and choes the option that expiorts functions, which created me a simple template project which I modified just a little and then built a release version, everything seemed to go well.

This is my class code

// Test.cpp : Defines the entry point for the DLL application.
//

#include "stdafx.h"
#include "Test.h"

BOOL APIENTRY DllMain( HANDLE hModule,
DWORD ul_reason_for_call,
LPVOID lpReserved
)
{
switch (ul_reason_for_call)
{
case DLL_PROCESS_ATTACH:
case DLL_THREAD_ATTACH:
case DLL_THREAD_DETACH:
case DLL_PROCESS_DETACH:
break;
}
return TRUE;
}


// This is an example of an exported variable
TEST_API int testVar1=0;

TEST_API int testVar2=0;

// This is an example of an exported function.
TEST_API int fnTest(void)
{
return 42;
}

// This is the constructor of a class that has been exported.
// see Test.h for the class definition
CTest::CTest()
{
return;
}

Now I am no C++ programmer, but this seemd straightforward, and looked as though it should do what I wanted (after provibg it, I would add many more variables of same simple type).

However, in VBA whenI tried to reference the DLL via the browse option, it told me it could not find the DLL (odd as I had browsed to it). If I tried to register the DLL, it returned an error saying that it could not register the dll as the DLLReisterServer entry point was not found.

Can anyone put me on the right track to allow me to access this dll from within VBA.

TIA

[Paul McKenzie]

However, in VBA whenI tried to reference the DLL via the browse option,

Before proceeding, can you call your exported DLL function from a C++ program? If not, make sure you can do that first to make sure that the function is properly exported.

Secondly, the type of DLL that you created is a "regular", non-ActiveX DLL's. You can't browse your DLL just like you can't browse a Windows system DLL.

The way you access/call exported DLL functions in any language is to read the documentation pertaining to that language on how to call exported DLL functions. This is the case for any language, whether it be VB, VBA, Delphi, etc. Each language has a different syntax for declaring, defining, and calling exported DLL functions.

For VBA, you have to declare an external function and the name of the DLL that the function resides in (I don't have the syntax in front of me, sorry). In other words, you have to call your function in VBA the same way you would call a Windows API function that resides in KERNEL32, USER32, GDI32 modules. I'm sure there has to be documentation on how to call these types of functions in VBA.

Regards,

Paul McKenzie

[martes]

Hi Paul,

Thanks for the response.

Before I answer the main thrust, as I said I am baby C++er, so I wouldn't know how to write a C++ program to test the exported function. I do know how to do it in VBA, you declare the function and then call it directly, but this also returns an error that it can't find the DLL entry point fnTest.

A bit more background. I am currently using a technique to register VBA UDFs in Excel, and this works by registering a function residing within any system dll, using an alias name which is identical to the name of a UDF. I am using user32.dll at the moment for this, but I am fast running out of appropriate functions within that dll, so I thougt I could create my own windows dll and create as many functions as I wanted there, removing the nervousness I have in using user32.dll, and giving me greater control.

As such, I don't actually have to set a reference, but I am getting an error with my dll that I don't get with user32.dll, and the fact that I could not register the dll made me suspicious, thinking that something is missing.

Let me ask a very straight question, does that code look enough to create a windows dll to you (albeit a functionally limited dll)?

[Paul McKenzie]

There are a few things wrong/missing from that code:

1) When writing a DLL function that is to be exported, use Windows types. For example, use LONG, not "int".

TEST_API LONG fnTest(void)

A LONG type is always 32-bits. However sizeof(int) could vary between compilers.

2) You need to use keywords such as dllexport, "extern "C"", and set the calling convention of the exported function correctly when defining the function.

3) You may also need to use a .DEF file if you want to export properly.

4) When the DLL is created, use programs such as DependencyWalker (DEPENDS.EXE) to verify that the function is exported, and the name of the function is correct.

I suggest you look at examples on how to create a Windows DLL in C++, since you totally missed item 2).

Regards,

Paul McKenzie

[martes]

This is exactly where I didn't want to go, back to square one and having to look up how to do it.

I used Visual C++ in Visual Studio 6 because it had an option to create a Win32 DLL, and further to create one that exports functions. I selected these options, and that code you saw is what it gave me. So I didn't miss anything, it just seems that the generated example in the tool is deficient.

Ah well!

[MrViggy]

Well, VS6 is oooooolllllllddddddd!

Viggy

[hoxsiew]

The TEST_API part in your sample code above should be a macro (in the .h file) that expands to:

__declspec(dllexport)

Change this to:

extern "C" __declspec( dllexport )

and your functions should be exportable AND usable by a non-C++ development platform like VB. If your VB is pre-VS2003, then you can't call __declspec calls (has to do with how the parameters a pushed onto the stack and how the stack is resored after the call) so you must declare your functions __stdcall and add a .DEF file with your exports.

// This is an example of an exported function.
__stdcall int fnTest(void)
{
  return 42;
}

.def file:

LIBRARY	"test"

EXPORTS
  fnTest

Ignore the example C++ exported class; that won't ever work with VB.

[Igor Vartanov]

This is exactly where I didn't want to go, back to square one and having to look up how to do it.

So you want to do it, but you do not want to look up how to do it... Sounds not inspiring.

Then the question is: why C++? Another question: why win32 dll?

I used Visual C++ in Visual Studio 6 because it had an option to create a Win32 DLL, and further to create one that exports functions. I selected these options, and that code you saw is what it gave me. So I didn't miss anything, it just seems that the generated example in the tool is deficient.

How can you state this being knowing nothing about how DLLs work?

It's not enough just to export a function to be able to use it in VBA. You have to remove the language barrier by following the rules of importing functions in VBA (mandatory __stdcall calling convention and exact function name declaration, this is what hoxsiew's post is about) and making used data types compatible in both languages (a couple of nasty surprises: strings and arrays). Are you still sure you don't want to look up anything?

[martes]

So you want to do it, but you do not want to look up how to do it... Sounds not inspiring.

At the risk of seeming like I am trying to be argumentative, which I am not, I did say that I had little C++ experience, and even less desire to learn it (I have far more interesting topics to stretch myself ).

Then the question is: why C++? Another question: why win32 dll?

Because the technique I am using requires Win32 DLLs. And have you ever tried creating Win32 DLLs in VB? ActiveX is fine, but Win32 is undocumented, unsupported, and hard work.

How can you state this being knowing nothing about how DLLs work?

Because the tool provides a wizard to create Win32 DLLs, and I just followed that. I added nothing, just changed some labels. I was informed by someone that I could use this method to create my Win32 DLL, but I ran into problems trying to use it. So clearly it was not correct in my particular circumstance, but my point is that I just let the product do the work.

It's not enough just to export a function to be able to use it in VBA. You have to remove the language barrier by following the rules of importing functions in VBA (mandatory __stdcall calling convention and exact function name declaration, this is what hoxsiew's post is about) and making used data types compatible in both languages (a couple of nasty surprises: strings and arrays). Are you still sure you don't want to look up anything?

This seems to be the crux. Unfortunately, lacking any C++ knowledge means that much of the suggestions are not clear to me at this point, and as I say, I have no desire to get C++ aware.

I might just have to follow another approach.

[Igor Vartanov]

Because the technique I am using requires Win32 DLLs.

And this naturally means you have to meet all the requirements I mentioned. Or just look up... Oops, sorry.

And have you ever tried creating Win32 DLLs in VB? ActiveX is fine, but Win32 is undocumented, unsupported, and hard work.

I have not, 'cause I have no problem with DLL programming in C/C++. Besides, fortunately the situation is quite rare in my projects. But in your case this means that you have to make your choice what language to use: C/C++, Delphi, Fortran, etc. And maybe the best way could be... to get rid of the said technique?

[martes]

Or just look up... Oops, sorry.

LOL! That is the difficult way that I mentioned. It is my intention to start down the lookup C++ road and see if it is achievable without too much pain. Wish me luck

I have not, 'cause I have no problem with DLL programming in C/C++. Besides, fortunately the situation is quite rare in my projects. But in your case this means that you have to make your choice what language to use: C/C++, Delphi, Fortran, etc. And maybe the best way could be... to get rid of the said technique?

The only time I needed C++ to any degree before I was in a position to just buy in the resource. I don't have that luxury now, and unfortunately that technique is the only way I know how to achieve my greater objective (intellisense in Excel 2007 UDFs in an addin in case you are interested).

As I said, I will give it a go, and hope I can get somewhere.

BTW, someone mentioned that VS6 is so old, which is a fair point, but what do you guys use for developing C++. VS2008 supports VB, C# and so on, but do you develop C++ in that environment?

[FrankieH]

but Win32 is undocumented

that's wrong

C++ ist only the coding language - but you must have some background knowledge to use your compiler properly, doesn't matter whether it is VS-6 or VS2005 or VS2008 or Watcom ...