VB5 Long & Double to VB.NET

[Terry]

I have some old VB5 functions that specify types of Long and Double that
make calls to an unmanaged 3rd party DLL probably just as old. The source
for the DLL is not available.

I'm getting some warnings "PInvoke..unbalanced stack..." etc. Reading up a
bit on this and trying to understand this particular warning, I find that
part of the problem could be in the mismatch of allocated space for the
variables, e.g. VB5 Long is not the same as VB2005 Long.

Another part is to do with the CallingConvention and for this I'm not all
too sure how to set this up.

Have I understood this warning and is there something that may be done to
correct the problem? I will add that I am converting an Access 2K3 VBA
application to VB.NET 2005. In the Access app all worked OK.

Regards

 

[Tom Shelton]

I have some old VB5 functions that specify types of Long and Double that
make calls to an unmanaged 3rd party DLL probably just as old. The source
for the DLL is not available.

I'm getting some warnings "PInvoke..unbalanced stack..." etc. Reading up a
bit on this and trying to understand this particular warning, I find that
part of the problem could be in the mismatch of allocated space for the
variables, e.g. VB5 Long is not the same as VB2005 Long.

Another part is to do with the CallingConvention and for this I'm not all
too sure how to set this up.

Have I understood this warning and is there something that may be done to
correct the problem? I will add that I am converting an Access 2K3 VBA
application to VB.NET 2005. In the Access app all worked OK.

Regards

Terry - the problem is most likely data size. Up until .NET, you
couldn't call anything but stdcall functions with declare statements
(without hacks). VB.NET will let you call cdecl, but stdcall is the
default.

In VB5/6 a Long was 32-bit. In VB.NET it is 64-bit. You need to
change it to Integer (32-bit in VB.NET). If making your datatypes the
right size doesn't fix the issue - then you might want to post the
function declarations (old and new).

 

[Terry]

Hi Tom,

Thanks for the info. I'll convert the Long's to int32 first to see if it
fixes the warnings. Failing that I'll post the the declarations.

Regards

Terry

 

[Terry]

Hi Tom,

Thanks for the help. Long to int32 did the trick. As I am calculating
astrological positions I find that there are some small differences between
the Access VBA results and VB.NET for the Sun and Moon of a couple of arc
seconds each that I will need to check out, apart from that all is working
out just fine now. It's great to finally get my first VB.NET solution
working thanks.

Regards
Terry

 

[Fabio Z]

Thanks for the help. Long to int32 did the trick. As I am calculating
astrological positions I find that there are some small differences
between the Access VBA results and VB.NET for the Sun and Moon of a couple
of arc seconds each that I will need to check out, apart from that all is
working out just fine now. It's great to finally get my first VB.NET
solution working thanks.

I suggest to don't tie to language-specific data type.
Instead of ambiguos Integer (vb6/vb.net) or int (c#) for extern dll calls
use Int32 that tell you immediatly that you are working with a 32 bit
integer.

 

[Armin Zingler]

I suggest to don't tie to language-specific data type.
Instead of ambiguos Integer (vb6/vb.net) or int (c#) for extern dll
calls use Int32 that tell you immediatly that you are working with a
32 bit integer.

Do you think, Integer will change in future again? Even if you target Win64,
Integer is still Int32. Just curious.


Armin

 

[Michael D. Ober]

Do you think, Integer will change in future again? Even if you target
Win64, Integer is still Int32. Just curious.


Armin

I'm sure it will change again. That's why the framework has int16, int32,
and int64. The C++ language definition of an integer is based on the native
word size of the processor. Yes, C# and VB (net versions) don't do this,
but C++ is still supported in dotNet.

Mike Ober.

 

[Armin Zingler]

I'm sure it will change again. That's why the framework has int16,
int32, and int64. The C++ language definition of an integer is
based on the native word size of the processor.
Yes, C# and VB (net versions) don't do this, but C++ is still supported
in dotNet.

If you want to use the "native Integer" size, use IntPtr. "Integer" is /not/
defined as "native integer" but as Int32, so this is not a criterion, IMO.

See also:
http://msdn2.microsoft.com/en-us/library/ms241064.aspx
http://msdn2.microsoft.com/en-us/library/8ck8e1y2.aspx



We don't know what future versions of VB will bring us (like the data type
changes from VB6 to .Net), but as we don't know of any fundamental
VB-data-type changes in the future, we can not handle them at all nowadays
anyway.


Armin