VB call DLL?
Jim
Hi
I wrote a VB program to call a VC DLL. I got a error message when I run
this VB program.
Error message is "Bad DLL calling convention"
The source of this VC DLL function is showed bellows
extern "C"
BOOL __declspec(dllexport) HM_OpenCommPort(UINT port,UINT nComBaud ,int
nComDataBit,int nComParity,int nComStopBit)
The declare in VB program is
Declare Function HM_OpenCommPort Lib "multidll" (ByVal port AsInteger,ByVal
nComBaud As Integer ,ByVal nComDataBit As Integer,ByVal nComParity As
Integer,ByVal nComStopBit As Integer) As Boolean
My VB program call this function as bellow
bRet = HM_OpenCommPort(2, 6, 8, 1, 0)
Someone could help me !
Think you very munch
Jim Wang
Jim
Dag Sunde
You have to use "PASCAL" calling convention when
you compile your C-DLL.
Dag
Jim <j...@unitech.com.tw> wrote in article <5rjnba$o...@netnews.hinet.net>...
Tim Pfeiffer
Assuming you are building 32 bit dll's and VB apps, you need to declare the
arguments in the VB prototype as Long (&). VB's Integer type is always 2
bytes. I'm a hardcore C/C++ programmer, but that's one point you've got to
score for VB, in my opinion.
I'm also suspicious of your return value declaration. Your VC 'BOOL' is
probably typedef'd as an int. It may function fine as is, and shouldn't
mess with the stack, but I would declare the VB return type as Long in this
case - I have no idea what VB uses for its 'Boolean' type.
I've done lots of working writing DLL's for use by VB and Access, and would
also warn you to remember that C 'char*' arguments are always 'ByVal
String$' types in VB. All other pointer arguments are 'ByRef'.
Jim <j...@unitech.com.tw> wrote in article <5rjnf9$o...@netnews.hinet.net>...
George Lucas
Hello Jim,
I have found that with a DEF file is always required. The only way around
it is if you use the Alias option in your VB Declare statement.
I tried declaring every way I could think of and was unable to get VB4 to
recognize the parameters. I finally gave up and used a DEF file with
EXPORTS statement.
Here is some useful documentation found in VC++ 5.0:
For DLLs to be called by programs written in the 32-bit version of Visual
Basic version 4.0, the alias technique shown in this article is needed in
the .DEF file. If alias is done in the Visual Basic program, use of
aliasing in the .DEF file is not necessary. It can be done on the Visual
Basic program by adding an alias clause to the declare statement as shown
here:
Declare Function MyFunc Lib "dlllibname" Alias "_MyFunc@12" (...)
As Integer
Hope this helps!
--
Cheers,
George Lucas
Interscape Corporation
Do you have AutoCAD development questions?
If so, visit: http://www.inters.com
Jim <j...@unitech.com.tw> wrote in article <5rjnba$o...@netnews.hinet.net>...
> Hi
>
> I wrote a VB program to call a VC DLL. I got a error message when I run
> this VB program.
> Error message is "Bad DLL calling convention"
>
>
> The source of this VC DLL function is showed bellows
> extern "C"
> BOOL __declspec(dllexport) HM_OpenCommPort(UINT port,UINT nComBaud ,int
> nComDataBit,int nComParity,int nComStopBit)
>
>
> The declare in VB program is
> Declare Function HM_OpenCommPort Lib "multidll" (ByVal port
AsInteger,ByVal
> nComBaud As Integer ,ByVal nComDataBit As Integer,ByVal nComParity As
> Integer,ByVal nComStopBit As Integer) As Boolean
>
>
Neil Schulman
I've been faced with this problem, too. And I've found an easier way
around
it than those shown below. The real problem is that C/C++ uses name
mangling in the executable (dll/exe) for function names that preserve
case, etc. VB doesn't like that. Nor does fortran. The way you can get
rid of the problem in both those (In fortran, you need an INTERFACE
statement)
is to use __stdcall in the VC++ DLL function and surround the whole
function
with extern "C"{}. Then as the person below remarked, add a DEF file
with
exports in the export section like:
EXPORTS
MyFunction @10
and your function header in VC++ is
extern "C"
{
__declspec( dllexport ) void __stdcall MyFunction()
{
}
}
Also, some extra hints: to pass a character pointer to a VC DLL, use
a ByVal mySTR as String in VB and a char * in VC. To pass back info to
VB,
the EASIEST way is to use a character array the EXACT SAME WAY as
above, but use the space command in the VB to pre-allocate space for
the largest you expect the string to be (you can trim later).
Like myText.Space(80)
I hope these little nuggets of wisdom help someone out there to
avoid the problems I faced when I first started writing these
things.
Good luck all!
Neil Schulman
------
Please note that the address in the mailto: has been changed to avoid
SPAM,
if you wish to send me a message, please write to
schu...@smtpg.compsys.com.
As usual, anything I say is my responsiblity alone.
> I have found that with a DEF file is always required. The only way around
> it is if you use the Alias option in your VB Declare statement.
[snips]
> Declare Function MyFunc Lib "dlllibname" Alias "_MyFunc@12" (...)
> As Integer
> > I wrote a VB program to call a VC DLL. I got a error message when I run
> > this VB program.
> > Error message is "Bad DLL calling convention"
[snip]
Jim Wang
Thank you for your solution.
There is one more question , if you are available.
For the STRING, I am not sure the length of return string. So I
pre-allocate a large enough space in VB. Now I don't know how to modify
length of this string in DLL.
Jim Wang
Neil Schulman 寫入到標題物件 <5sn2ed$54q$1...@news.usit.net>...
Wayne D. Hoxsie Jr.
On 30 Jul 1997 15:24:57 GMT, "Tim Pfeiffer" <ti...@pacercats.com>
wrote:
>Assuming you are building 32 bit dll's and VB apps, you need to declare the
>arguments in the VB prototype as Long (&). VB's Integer type is always 2
>bytes. I'm a hardcore C/C++ programmer, but that's one point you've got to
>score for VB, in my opinion.
Remember that C was designed for portability across platforms.
The C standard provides that for the `int' type, the width should be
the most efficient type for the machine's architecture. Since Intel
can't seem to decide what architecture is the most efficient (see the
new Pentium 2 specs) and Microsoft can't seem to force people away
from legacy 16 bit platforms, we are stuck (for now) with this dilemma
when it comes to integrating code from different bases.
IMHO this is a minor nuisance compared to the problems of passing data
structure, UNICODE, VARIANT types, callback addresses, etc.
--
Wayne D. Hoxsie Jr.
wa...@hoxnet.com
http://hox.spiff.net