I've come up against a problem that I've never dealt with before. I have a DLL that I want to be able to use from a Visual Basic (6) app, but the DLL was not written to be used by VB (no SAFEARRAY, etc.). How can I use it? I thought of writing another DLL which just wrapped up this DLL's functions and then using that, but I don't really know how to do that. I've never written a DLL for VB before, and the process seems to be complicated by a)writing a DLL that links another DLL and b)by some complicated structs that contain arrays. I would appreciate any help. I'm not asking you to write code for me (though I certainly wouldn't refuse it), just some help as to how to go about doing it. Or, if there's another way, that's fine, too. Thanks. Oh, the list of function definitions in the DLL is here. Thanks all in advance. [edit] It also appears that it was not compiled with a .DEF file, so I can't even reference it from VB.

No, that's not the problem. I've use API and DLL's before (oh, so many times...). The problem is re-writing the DLL (or doing something else) in C++ so that it interfaces properly with Visual Basic.

Thanks for the reply, though.

It is possible to use the DLL directly as-is, by means of using the MoveMemory API function as a workaround for the fact that VB doesn't have pointers. The calling convention is already correct.
However, this doen't make for very nice VB code at all.

It could indeed be best to wrap it in another DLL with safearrays, and that's not a hard thing to do. You'd only need to wrap three of those functions. Just make a DLL which exports the functions using

extern "C" __declspec(dllexport) int __stdcall

and put the function names in a .def file.
Get familiar with depends.exe if you aren't already.

Just start out doing it and see how far you get. We'll help you with any problems you come across.

OK, here's what I know (or think I know):

I need to do

HINSTANCE hDll = LoadLibrary("C:\documents and settings\jr\desktop\suo_11_eng.dll");

to import the existing DLL in C++, then close free it with FreeLibrary.

----------

I need to do a few lines like

typedef int (*FPTR_Solve)(int, int, int, int, int, int*);FPTR_Solve Solve;Solve = (FPTR_Solve)GetProcAddress(hDll, "Solve");

to use the functions in the existing DLL (in this case, the Solve function)

----------

I need to create a new function like

int __declspec(dllexport) solve(int guessOnly, int guessExcluded, int diagonalVers, int diff, LPSAFEARRAY FAR *v){    //then convert the SAFEARRAY to a C-style array    int* temp;    temp = (int*)(*v)->pvData;        //then call the function, like    Solve(guessOnly, guessExcluded, diagonalVers, diff, temp);}

that I can then call from VB.

----------

I need to define the functions in a .DEF file, like:

LIBRARY "whateverLib"DESCRIPTION "Allows the use of whatever.dll with VB"EXPORTS	solve	@1

so that VB knows what it's looking at.

##########
==========
##########

Things I don't know:

-Where does the code go? Where does the code to import the DLL and the functions go? Does it go in a seperate function? Is there, like, a DLL constructor or something?

-Did I do the SAFEARRAY thing right? It's a 2D array. Does that matter? (Assume windows.h is included)

-How do I handle the structs, especially since they have arrays in them?

-You said I only needed to wrap 3 functions. Would I just reference the other DLL in VB and use the functions straight from that?

==========
==========

So, what's right and what's not? What did I not include?

Thanks a bunch in advance. I know this probably sounds like n00b stuff or something. I know VB, and I know C++, but I've never used them together before.

Thanks again.

[Edited by - ricekrispyw on December 31, 2005 12:36:23 AM]

Quote:Original post by ricekrispyw
OK, here's what I know (or think I know):

I need to do

HINSTANCE hDll = LoadLibrary("C:\documents and settings\jr\desktop\suo_11_eng.dll");

to import the existing DLL in C++, then close free it with FreeLibrary.

----------

I need to do a few lines like

typedef int (*FPTR_Solve)(int, int, int, int, int, int*);FPTR_Solve Solve;Solve = (FPTR_Solve)GetProcAddress(hDll, "Solve");

to use the functions in the existing DLL (in this case, the Solve function)

Yes that's the way to load the DLL dynamically. You can also statically link to it, but either way is fine.

Quote:I need to create a new function like

int __declspec(dllexport) solve(int guessOnly, int guessExcluded, int diagonalVers, int diff, LPSAFEARRAY FAR *v){    //then convert the SAFEARRAY to a C-style array    int* temp;    temp = (int*)(*v)->pvData;        //then call the function, like    Solve(guessOnly, guessExcluded, diagonalVers, diff, temp);}

that I can then call from VB.

It'll take a bit more than that. First off, you'll probably want to do it by locking the safearray. Secondly, since it's a 2dsafearray it'll be a bit more complicated to get the items into a plain old 2D array.

Quote:
I need to define the functions in a .DEF file, like:

LIBRARY "whateverLib"DESCRIPTION "Allows the use of whatever.dll with VB"EXPORTS	solve	@1

so that VB knows what it's looking at.

Yep, though it's primarily so that the names aren't mangled.

Quote:
Things I don't know:

-Where does the code go? Where does the code to import the DLL and the functions go? Does it go in a seperate function? Is there, like, a DLL constructor or something?

You could provide an init function. Linking statically to the original DLL would prevent the need for that though.

Quote:

-Did I do the SAFEARRAY thing right? It's a 2D array. Does that matter? (Assume windows.h is included)

No, it is quite a bit more complicated than you thought. You'll want to use SafeArrayAcccessData and SafeArrayUnaccessData etc, and each element itself will be a safearray, for which you'll want to do the same thing.

Quote:

-How do I handle the structs, especially since they have arrays in them?

There shouldn't be any problems. You just need to copy the string out of the BSTR into the char array.

Quote:

-You said I only needed to wrap 3 functions. Would I just reference the other DLL in VB and use the functions straight from that?

Yep, that's what I would do.

I would like to load the DLL statically, but I don't have a lib file, so no dice there.

I'll take a deeper look into SAFEARRAY and how to lock it and get information from it. Thanks.

So, if I provided an init function, in VB, maybe in the form load, I would call the function, and then proceed to use the other functions. It's that simple?

And, about the structs, do I need to do anything special to get the information in the arrays? Do I need to define equivilant types in VB?

Thanks a lot. You're a big help.

Quote:I would like to load the DLL statically, but I don't have a lib file, so no dice there.

If I remember correctly, you can use lib.exe in combination with a basic def file( simply listing the functions) to produce a lib.

Quote:So, if I provided an init function, in VB, maybe in the form load, I would call the function, and then proceed to use the other functions. It's that simple?

Yep.

Quote:And, about the structs, do I need to do anything special to get the information in the arrays? Do I need to define equivilant types in VB?

Oh heck, yeah I just realised that one of those arrays is of structs which also contains an array. I see what you're talking about. This aint no walk in the park. I've only dealt with safearrays at work, not at home. So I don't have any examples handy to work with. Still I might be able to work it out tomorrow. It's quite late at the moment.

I strongly suggest looking for some tutorials about passing data between VB and a DLL, for now.

Is it possible that you could shift more of the work to the DLL, so that you don't have to do much form the VB end? For example if in VB you were simply reading the data from a file, perhaps that could be done directly from the DLL. That example probably isn't the case, but it might give you an idea to make this easier.

Yeah, last night when I was going to bed, I thought VB really doesn't have to know about much at all. I could do all the heavy work in the DLL and then provide a simple interface to VB. I think that's what I'll do.

I'll keep you posted and I *really* appreciate your help. Thanks a bunch.

Ah that's great. That'll be much easier if you can do a litle more in the DLL to prevent having so much cross-language stuff to deal with. Let us know if you have any problems with making your first DLL. I can remember back to when I hadn't ever created a DLL.