Calling Into Drivers - VB6 vs. VB.NET

[Jason Teagle]

A client using some drivers of ours has been able to communicate with them
quite happily when writing their source code in VB6. They've now ended up
with VB.NET, and suddenly find they can't communicate with them any more.

Are there known issues with .NET-generated VB communicating with DLLs /
drivers?

 

[Herfried K. Wagner]

Hello,

Are there known issues with .NET-generated VB
communicating with DLLs / drivers?

No, but very often people use buggy API declares.

Regards,
Herfried K. Wagner

 

[Jeremy Cowles]

A client using some drivers of ours has been able to communicate with them
quite happily when writing their source code in VB6. They've now ended up
with VB.NET, and suddenly find they can't communicate with them any more.

Are there known issues with .NET-generated VB communicating with DLLs /
drivers?

This is a C/C++ DLL right? Assuming that it is, your client has probably
ported the Declares, Structures or Constants wrong. Here are the key things
to have them check for (in the conversion from VB6 to .NET):

- Convert all Integers to Shorts
- Convert all Longs to Integers
- Any function parameters that are missing ByVal / ByRef should be
explicitly declared as ByRef
- When passing structures to methods/functions, make sure the parameter is
always declared as ByRef *explicitly*
- Verify that all strings are marshaled as the right width (double byte
Unicode or single byte ANSI). This can be adjusted by applying the
<MarshalAs( )> attribute to the string (in a function call or structure).

That covers most of the major porting issues...

HTH,
Jeremy

 

[Jason Teagle]

No, but very often people use buggy API declares.

Interesting point, I'll get them to check.