DLL written in c + + header file, function are defined as follows

Int EXPORT_API usb_relay_device_open_with_serial_number (const char * serial_number, unsigned len);
/* open device that serial number is serial number */
/* return: This funcation return a valid handle to the device on success, or NULL on failure */
Eg:/* * usb_relay_device_open_with_serial_number (" abcde ", 5 ") */


Try the following several ways to write program in vb (equipment serial number for "QAAMZ")
1, direct transmission string
Disclaimer:
Private declare function usb_relay_device_open_with_serial_number Lib "xx path" (byval SerNum as string, byval lenth as long) as long
The
Dim return as long
Return=usb_relay_device_open_with_serial_number (" QAAMZ ", 5)
2, passing a pointer
Statement, byval SerNum as long
Including sernum for serial number first character array pointer address

But both "DLL calling convention error",

Consult ~

Ps: this problem lead to ask: https://bbs.csdn.net/topics/392563831
Has solved the question using DLL for equipment serial number,

CodePudding user response:

Change statement into a pointer parameter C, VB inside with byref incoming, type of any
Private declare function usb_relay_device_open_with_serial_number Lib "xx path" (byref SerNum as any, byval lenth as long) as long

Next, the char C is actually an array of bytes, the VB string into an array of bytes

Dim (a) as byte
A=strconv (" abcd "1234, vbfromunicode)

Finally, pass the first element of the array, DLL there is obtained by the array in the starting address of the memory, namely the array pointer,
Dim return as long
Return=usb_relay_device_open_with_serial_number (a (0), ubound (a) + 1)

CodePudding user response:

reference 1/f, crispy big ice cream reply:

change the statement into a pointer parameter C, VB inside with byref incoming, type of any
Private declare function usb_relay_device_open_with_serial_number Lib "xx path" (byref SerNum as any, byval lenth as long) as long

Next, the char C is actually an array of bytes, the VB string into an array of bytes

Dim (a) as byte
A=strconv (" abcd "1234, vbfromunicode)

Finally, pass the first element of the array, DLL there is obtained by the array in the starting address of the memory, namely the array pointer,
Dim return as long
Return=usb_relay_device_open_with_serial_number (a (0), ubound (a) + 1)

The great god, or not, or the DLL error calling conventions, this method also before I tried, will not be in addition to a pointer, other places I didn't notice the mistakes,

CodePudding user response:

Vc DLL set invocation pattern for _stdcall is needed to make the vb call
Such as function:
Void the add (int a, int b)
Will not be able to call in VB
To change to:
Void the add _stdcall (int a, int b)

From:
https://bbs.csdn.net/topics/350190581
The second floor;

CodePudding user response:

reference milaoshu1020 reply: 3/f

vc DLL set invocation pattern for _stdcall is needed to make the vb call
Such as function:
Void the add (int a, int b)
Will not be able to call in VB
To change to:
Void the add _stdcall (int a, int b)

From:
https://bbs.csdn.net/topics/350190581
The second floor;

I haven't seen the inside of the DLL code, but have two function has run into, before should be stdcall?

CodePudding user response:

reference 4 floor assummerflower response:

Quote: reference milaoshu1020 reply: 3/f

vc DLL set invocation pattern for _stdcall is needed to make the vb call
Such as function:
Void the add (int a, int b)
Will not be able to call in VB
To change to:
Void the add _stdcall (int a, int b)

From:
https://bbs.csdn.net/topics/350190581
The second floor;

I haven't seen the inside of the DLL code, but have two function has run into, before should be stdcall?

What's it like in reference to the function of statement?

CodePudding user response:

reference 5 floor milaoshu1020 reply:

Quote: refer to 4th floor assummerflower response:

Quote: refer to the third floor milaoshu1020 response:

vc DLL set invocation pattern for _stdcall is needed to make the vb call
Such as function:
Void the add (int a, int b)
Will not be able to call in VB
To change to:
Void the add _stdcall (int a, int b)

From:
https://bbs.csdn.net/topics/350190581
The second floor;

I haven't seen the inside of the DLL code, but have two function has run into, before should be stdcall?

What's it like in reference to the function of statement?

Reference into two functions,
1, the initialization function
In the DLL for declaration in the header file:
Int EXPORT_API usb_relay_init (void)
/* init the usb relay library
Return 0 on success and 1 on failure */
In vb declared
Private declare function usb_relay_init lib. "path" () as long
2, the second function is to scan equipment information, in another post, the great god you reply to me, according to your method solved,

Ps: if you want to modify the stdcall DLL, should be how to modify, there are. CPP,. H,. Lib and. DLL several files, which should be changed?

CodePudding user response:

, CPP, h is a source code file;
Try to modify. CPP,. H (to export the function name in the front plus _stdcall);
For example:
Int _stdcall EXPORT_API usb_relay_device_open_with_serial_number (const char * serial_number, unsigned len);
. Lib and. DLL is compiled file, the DLL is actual using vb6 file;

Because I haven't tested, just look at the others say, so I'm not sure this method can achieve the effect;
You can give it a try, no longer want to other way;

CodePudding user response:

To be invoked by VB function to use stdcall

CodePudding user response:

Stdcall calling convention means: parameters onto the stack from right to left, the called function itself to modify the stack
Stack order is cdecl calling conventions of the parameters and stdcall is same, parameters of the first by a left onto the stack, the difference is that the called function itself is not clean up the stack, the caller is responsible for cleaning up the stack,
VB call way is not to clean up the stack, in fact, WINDOWS API functions are basically stdcall,

_cdecl is invoked by default way of C and C + + programs,
nullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnull