By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
448,672 Members | 1,628 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 448,672 IT Pros & Developers. It's quick & easy.

VB5 Long & Double to VB.NET

P: n/a
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

Jan 22 '07 #1
Share this Question
Share on Google+
17 Replies


P: n/a

Terry wrote:
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).

--
Tom Shelton

Jan 22 '07 #2

P: n/a
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

"Tom Shelton" <to*********@comcast.netwrote in message
news:11*********************@v45g2000cwv.googlegro ups.com...
>
Terry wrote:
>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).

--
Tom Shelton

Jan 22 '07 #3

P: n/a
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

"Tom Shelton" <to*********@comcast.netwrote in message
news:11*********************@v45g2000cwv.googlegro ups.com...
>
Terry wrote:
>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).

--
Tom Shelton

Jan 23 '07 #4

P: n/a
"Terry" <ne*******@whiteHYPHENlightDOTme.ukha scritto nel messaggio
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.
Jan 23 '07 #5

P: n/a
"Fabio Z" <zn*******@virgilio.itschrieb
"Terry" <ne*******@whiteHYPHENlightDOTme.ukha scritto nel
messaggio
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.

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

Jan 23 '07 #6

P: n/a

"Armin Zingler" <az*******@freenet.dewrote in message
news:ev**************@TK2MSFTNGP03.phx.gbl...
"Fabio Z" <zn*******@virgilio.itschrieb
>"Terry" <ne*******@whiteHYPHENlightDOTme.ukha scritto nel
messaggio
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.


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.
Jan 23 '07 #7

P: n/a
"Michael D. Ober" <obermd.@.alum.mit.edu.nospamschrieb
Do you think, Integer will change in future again? Even if you
target Win64, Integer is still Int32. Just curious.

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

Jan 23 '07 #8

P: n/a
Armin,

Even Herfried is now advising to use the Int32 in API's.

I find it one of the stupidest decisions to let the Integer not to be the
same as the internal size of an accumulator. If that was than most programs
would benefit from the performance enhancements without rewriting,
rebuilding is than enough. However I thought it was the VB6 lobby which
forces us now to change all integers in Int64 and latter probably in Int128.

Cor

"Armin Zingler" <az*******@freenet.deschreef in bericht
news:ev**************@TK2MSFTNGP03.phx.gbl...
"Fabio Z" <zn*******@virgilio.itschrieb
>"Terry" <ne*******@whiteHYPHENlightDOTme.ukha scritto nel
messaggio
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.


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

Jan 23 '07 #9

P: n/a
Cor,

The variable size of the "C/C++" int data type has, over the years, caused
almost as many problems for programmers as buffer overruns. Defining the
size is actually a good thing, so long as you have other numeric data types
that work like int but allow full access to the processor word length.

Mike.

"Cor Ligthert [MVP]" <no************@planet.nlwrote in message
news:ur**************@TK2MSFTNGP06.phx.gbl...
Armin,

Even Herfried is now advising to use the Int32 in API's.

I find it one of the stupidest decisions to let the Integer not to be the
same as the internal size of an accumulator. If that was than most
programs would benefit from the performance enhancements without
rewriting, rebuilding is than enough. However I thought it was the VB6
lobby which forces us now to change all integers in Int64 and latter
probably in Int128.

Cor

"Armin Zingler" <az*******@freenet.deschreef in bericht
news:ev**************@TK2MSFTNGP03.phx.gbl...
>"Fabio Z" <zn*******@virgilio.itschrieb
>>"Terry" <ne*******@whiteHYPHENlightDOTme.ukha scritto nel
messaggio

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.


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


Jan 23 '07 #10

P: n/a
"Armin Zingler" <az*******@freenet.deha scritto nel messaggio
Do you think, Integer will change in future again? Even if you target
Win64, Integer is still Int32. Just curious.
I don't know.
I just think that "integer" is ambiguos.
Jan 24 '07 #11

P: n/a
Well, if you don't know, then don't pontificate!.

Integer is a synonym for System.Int32 just as, in C#, int is a synonym for
System.Int32 and that's all there is to it.
"Fabio" <zn*******@virgilio.itwrote in message
news:%2***************@TK2MSFTNGP02.phx.gbl...
"Armin Zingler" <az*******@freenet.deha scritto nel messaggio
>Do you think, Integer will change in future again? Even if you target
Win64, Integer is still Int32. Just curious.

I don't know.
I just think that "integer" is ambiguos.


Jan 24 '07 #12

P: n/a
Stephany,

However more the standard format from the internal register. It is the best
value size to use in a computer.

In 16bits computers it was forever Int16, now it became Int32, and it had to
be Int64 but that did not happen because of the big lobby I thought from the
VB6 groups.

The comments from some Microsoft employee's I heard on that was that it
hurts not so much because computers are so much faster to day. However it is
especially relative much slower than it can be. Therefore you can optimize
in future by renaming all your Integers to Int64 (which would have been
automatic if Microsoft had not listen so much to the lobby).

Cor

"Stephany Young" <noone@localhostschreef in bericht
news:Oj**************@TK2MSFTNGP06.phx.gbl...
Well, if you don't know, then don't pontificate!.

Integer is a synonym for System.Int32 just as, in C#, int is a synonym for
System.Int32 and that's all there is to it.
"Fabio" <zn*******@virgilio.itwrote in message
news:%2***************@TK2MSFTNGP02.phx.gbl...
>"Armin Zingler" <az*******@freenet.deha scritto nel messaggio
>>Do you think, Integer will change in future again? Even if you target
Win64, Integer is still Int32. Just curious.

I don't know.
I just think that "integer" is ambiguos.



Jan 24 '07 #13

P: n/a
"Stephany Young" <noone@localhostha scritto nel messaggio
news:Oj**************@TK2MSFTNGP06.phx.gbl...

Well, if you don't know, then don't pontificate!.
Just following your kindness: are you joking or are you a serious idiot?

Integer is a synonym for System.Int32 just as, in C#, int is a synonym for
System.Int32 and that's all there is to it.
In VB.net 2005 may be, but
Referring to your question: do you know if it will change? If not (unless
you're a prophet and I don't really think) you would prefere the more clear
way.
How many times VB6 programmers tell that they have an unbalanced call stack
due to the "obvious" Integer IS 32 bits?
Why does MICROSOFT guidelines (not mine!) tell you to use language
indipendent data type names when you're working with different languages?
Int32 not Integer or int, DateTime not Date, Int16 not Short or short, Byte
not byte.
Did you never seen a Convert.ToInteger()? In your trash code maybe.
But it's just MORE clear, and this would be enought to make you use it.
I don't know why VB NGs are full of people that think that a VB6 programmer
is a real code master and don't need to follow "stupid" basic programming
rules that all the rest of the programming world are used to.

Jan 24 '07 #14

P: n/a
Did you never seen a Convert.ToInteger()?

Of course not! For the same reason that there is no Convert.Toint method.

The Convert class is part of the Framework and therefore it's methods are
the same regardless of which language you are using.

If you want to use declare 'Int32' or more correctly 'System.Int32', in your
code, instead of Integer then that is up to you but do not try to tell
people that they must do as you do.
Referring to your question: do you know if it will change?
Of course not! I do not have any evidence that it will and I do not have any
evidence that it will not. In the abscence of any such evidence then we can
only be guided by the status quo.

If you have any evidence that there will be a change then present it by all
means.
"Fabio" <zn*******@virgilio.itwrote in message
news:u9**************@TK2MSFTNGP02.phx.gbl...
"Stephany Young" <noone@localhostha scritto nel messaggio
news:Oj**************@TK2MSFTNGP06.phx.gbl...

>Well, if you don't know, then don't pontificate!.

Just following your kindness: are you joking or are you a serious idiot?

>Integer is a synonym for System.Int32 just as, in C#, int is a synonym
for System.Int32 and that's all there is to it.

In VB.net 2005 may be, but
Referring to your question: do you know if it will change? If not (unless
you're a prophet and I don't really think) you would prefere the more
clear way.
How many times VB6 programmers tell that they have an unbalanced call
stack due to the "obvious" Integer IS 32 bits?
Why does MICROSOFT guidelines (not mine!) tell you to use language
indipendent data type names when you're working with different languages?
Int32 not Integer or int, DateTime not Date, Int16 not Short or short,
Byte not byte.
Did you never seen a Convert.ToInteger()? In your trash code maybe.
But it's just MORE clear, and this would be enought to make you use it.
I don't know why VB NGs are full of people that think that a VB6
programmer is a real code master and don't need to follow "stupid" basic
programming rules that all the rest of the programming world are used to.

Jan 24 '07 #15

P: n/a
I needed to carry out a convertion and found a possible solution in Help.
The Dim statements give me the result I need, I suspect there may be other
ways to do this in the .NET Framework. What would they be?

Regards
Terry

Public Shared Sub Calc_House_Positions(ByVal BirthDateTime As DateTime, _

ByVal GeoLat As Double, ByVal GeoLon As Double, ByVal hsys As Integer)

Dim BirthDate As String = BirthDateTime.ToShortDateString

Dim BirthTime As String = BirthDateTime.ToShortTimeString

"Fabio" <zn*******@virgilio.itwrote in message
news:u9**************@TK2MSFTNGP02.phx.gbl...
"Stephany Young" <noone@localhostha scritto nel messaggio
news:Oj**************@TK2MSFTNGP06.phx.gbl...

>Well, if you don't know, then don't pontificate!.

Just following your kindness: are you joking or are you a serious idiot?

>Integer is a synonym for System.Int32 just as, in C#, int is a synonym
for System.Int32 and that's all there is to it.

In VB.net 2005 may be, but
Referring to your question: do you know if it will change? If not (unless
you're a prophet and I don't really think) you would prefere the more
clear way.
How many times VB6 programmers tell that they have an unbalanced call
stack due to the "obvious" Integer IS 32 bits?
Why does MICROSOFT guidelines (not mine!) tell you to use language
indipendent data type names when you're working with different languages?
Int32 not Integer or int, DateTime not Date, Int16 not Short or short,
Byte not byte.
Did you never seen a Convert.ToInteger()? In your trash code maybe.
But it's just MORE clear, and this would be enought to make you use it.
I don't know why VB NGs are full of people that think that a VB6
programmer is a real code master and don't need to follow "stupid" basic
programming rules that all the rest of the programming world are used to.

Jan 24 '07 #16

P: n/a
You really should have created a new thread for this Terry, because it is
unrelated to the thread you have posted it against.

If you want the date and time parts of BirthDateTime as seperate strings for
display purposes then that is absoulutely fine.

If you wanted BirthDateTime as a single string in short date/short time
format for display purposes then you could use:

Dim DisplayBirthDateTime As String = BirthDateTime.ToString("g")
"Terry" <ne*******@whiteHYPHENlightDOTme.ukwrote in message
news:Of**************@TK2MSFTNGP05.phx.gbl...
>I needed to carry out a convertion and found a possible solution in Help.
The Dim statements give me the result I need, I suspect there may be other
ways to do this in the .NET Framework. What would they be?

Regards
Terry

Public Shared Sub Calc_House_Positions(ByVal BirthDateTime As DateTime, _

ByVal GeoLat As Double, ByVal GeoLon As Double, ByVal hsys As Integer)

Dim BirthDate As String = BirthDateTime.ToShortDateString

Dim BirthTime As String = BirthDateTime.ToShortTimeString

"Fabio" <zn*******@virgilio.itwrote in message
news:u9**************@TK2MSFTNGP02.phx.gbl...
>"Stephany Young" <noone@localhostha scritto nel messaggio
news:Oj**************@TK2MSFTNGP06.phx.gbl...

>>Well, if you don't know, then don't pontificate!.

Just following your kindness: are you joking or are you a serious idiot?

>>Integer is a synonym for System.Int32 just as, in C#, int is a synonym
for System.Int32 and that's all there is to it.

In VB.net 2005 may be, but
Referring to your question: do you know if it will change? If not (unless
you're a prophet and I don't really think) you would prefere the more
clear way.
How many times VB6 programmers tell that they have an unbalanced call
stack due to the "obvious" Integer IS 32 bits?
Why does MICROSOFT guidelines (not mine!) tell you to use language
indipendent data type names when you're working with different languages?
Int32 not Integer or int, DateTime not Date, Int16 not Short or short,
Byte not byte.
Did you never seen a Convert.ToInteger()? In your trash code maybe.
But it's just MORE clear, and this would be enought to make you use it.
I don't know why VB NGs are full of people that think that a VB6
programmer is a real code master and don't need to follow "stupid" basic
programming rules that all the rest of the programming world are used to.


Jan 24 '07 #17

P: n/a
Thanks Stephany,

Thanks for info. Sorry about the OT.
Regards
Terry

"Stephany Young" <noone@localhostwrote in message
news:%2****************@TK2MSFTNGP04.phx.gbl...
You really should have created a new thread for this Terry, because it is
unrelated to the thread you have posted it against.

If you want the date and time parts of BirthDateTime as seperate strings
for display purposes then that is absoulutely fine.

If you wanted BirthDateTime as a single string in short date/short time
format for display purposes then you could use:

Dim DisplayBirthDateTime As String = BirthDateTime.ToString("g")
"Terry" <ne*******@whiteHYPHENlightDOTme.ukwrote in message
news:Of**************@TK2MSFTNGP05.phx.gbl...
>>I needed to carry out a convertion and found a possible solution in Help.
The Dim statements give me the result I need, I suspect there may be other
ways to do this in the .NET Framework. What would they be?

Regards
Terry

Public Shared Sub Calc_House_Positions(ByVal BirthDateTime As DateTime, _

ByVal GeoLat As Double, ByVal GeoLon As Double, ByVal hsys As Integer)

Dim BirthDate As String = BirthDateTime.ToShortDateString

Dim BirthTime As String = BirthDateTime.ToShortTimeString

"Fabio" <zn*******@virgilio.itwrote in message
news:u9**************@TK2MSFTNGP02.phx.gbl...
>>"Stephany Young" <noone@localhostha scritto nel messaggio
news:Oj**************@TK2MSFTNGP06.phx.gbl...
Well, if you don't know, then don't pontificate!.

Just following your kindness: are you joking or are you a serious idiot?
Integer is a synonym for System.Int32 just as, in C#, int is a synonym
for System.Int32 and that's all there is to it.

In VB.net 2005 may be, but
Referring to your question: do you know if it will change? If not
(unless you're a prophet and I don't really think) you would prefere the
more clear way.
How many times VB6 programmers tell that they have an unbalanced call
stack due to the "obvious" Integer IS 32 bits?
Why does MICROSOFT guidelines (not mine!) tell you to use language
indipendent data type names when you're working with different
languages? Int32 not Integer or int, DateTime not Date, Int16 not Short
or short, Byte not byte.
Did you never seen a Convert.ToInteger()? In your trash code maybe.
But it's just MORE clear, and this would be enought to make you use it.
I don't know why VB NGs are full of people that think that a VB6
programmer is a real code master and don't need to follow "stupid" basic
programming rules that all the rest of the programming world are used
to.



Jan 25 '07 #18

This discussion thread is closed

Replies have been disabled for this discussion.