Calling Into Drivers - VB6 vs. VB.NET

  • Thread starter Thread starter Jason Teagle
  • Start date Start date
J

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?
 
Hello,

Jason Teagle said:
Are there known issues with .NET-generated VB
communicating with DLLs / drivers?
Click to expand...

No, but very often people use buggy API declares.

Regards,
Herfried K. Wagner
 
Jason Teagle said:
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?
Click to expand...

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
 
No, but very often people use buggy API declares.

Interesting point, I'll get them to check.
 
Back
Top