Re: DLL API Calling Issue
- From: "Ralph" <nt_consulting64@xxxxxxxxx>
- Date: Thu, 7 Sep 2006 12:30:52 -0500
"Wyne" <Wyne@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
news:C390E72D-4475-4839-B3C8-2BFD531D74E3@xxxxxxxxxxxxxxxx
<snipped>
OK, here's my guess... <g>
Note this define...
#define CPLUSPLUS
Normally one doesn't do this as the compiler being used will define it.
Anyway this forces the exports to be C++ unless a DEF file is used. But we
have no way of knowing. That is why the dumpbin results would have been very
useful. Did you get that working yet?
I suspect however, that since the intermediate dll can 'see' xxxxx.dll just
fine, and VB can not, then a DEF was not used and the functions were not
exported as extern C, and thus unuseable from VB. Your intermediate is
likely exporting its API/Interface correctly.
If I am correct then the /Exports section would have shown some squirrelly
names.
To use this DLL from VB (again IF I am correct) you have only two choices:
1) Create an ActiveX component wrapper around the dll.
ATL would be the simplest and easiest way to implement it.
VB loves ActiveX components, plus you would confine all your 'translations',
massages, etc. to one component.
It makes it easier to export all those structs and enums so you don't have
to write and debug VB equivalents.
But may or may not have a slight performance penality.
Or 2) Just use your intermediate dll. Hey if it works, it works. <g>
Using the dll directly will not be an option.
-ralph
.
- Follow-Ups:
- Re: DLL API Calling Issue
- From: Ralph
- Re: DLL API Calling Issue
- References:
- Re: DLL API Calling Issue
- From: J French
- Re: DLL API Calling Issue
- From: Ralph
- Re: DLL API Calling Issue
- From: Wyne
- Re: DLL API Calling Issue
- Prev by Date: Re: Sudoku Challenge !
- Next by Date: Re: Delete Key in a Text Box
- Previous by thread: Re: DLL API Calling Issue
- Next by thread: Re: DLL API Calling Issue
- Index(es):
Relevant Pages
|