GetTickCount() confusion in VB

[Alain Dekker]

I know how to privately declare a function exported from kernel32.dll as
follows:
Private Declare Function GetTickCount Lib "kernel32 as Long

and then to use code like this:
Dim lElapsed as Long
lElapsed = (GetTickCount() - lPreviousTimeValue)
' etc

but I'm curious. Why is the type Long? The VB.NET (2003.NET) documentation
tells me that a Long is a 64-bit signed number. In my experience of all
previous compilers (Delphi 7, Visual C++, etc), I'ce always known
GetTickCount() to return a DWORD (unsigned 32-bit number).

In fact, the MSDN documentation states that:
DWORD WINAPI GetTickCount(void);
http://msdn.microsoft.com/en-us/library/ms724408(VS.85).aspx

Why does VB return a signed 64-bit number? Why doesn't VB have a unsigned
32-bit integer data type anyway? Its got a 8-bit and 16-bit unsigned type,
but no 32-bit unsigned.

Also, what are the units of the VB GetTickCount version? Again, in all
previous compilers it was in ms, is that still the case?

Thanks,
Alain

 

[Armin Zingler]

I know how to privately declare a function exported from kernel32.dll as
follows:
Private Declare Function GetTickCount Lib "kernel32 as Long

and then to use code like this:
Dim lElapsed as Long
lElapsed = (GetTickCount() - lPreviousTimeValue)
' etc

but I'm curious. Why is the type Long?

Because your declaration is wrong.

The VB.NET (2003.NET) documentation
tells me that a Long is a 64-bit signed number. In my experience of all
previous compilers (Delphi 7, Visual C++, etc), I'ce always known
GetTickCount() to return a DWORD (unsigned 32-bit number).

Yes, that's why the return value has to be UInteger (or UInt32)
in VB 2005/2008. In VB 2003, you were able to declare it as
Integer or Int32 which is at least the right bitness (32).

UInt32 was already there in FW 1.1:
http://msdn.microsoft.com/en-us/library/hfa3fa08(VS.71).aspx
However, the type wasn't "CLS compliant", and VB 2003 didn't have
a mapped native type like UInteger yet.

In fact, the MSDN documentation states that:
DWORD WINAPI GetTickCount(void);
http://msdn.microsoft.com/en-us/library/ms724408(VS.85).aspx

Why does VB return a signed 64-bit number? Why doesn't VB have a unsigned
32-bit integer data type anyway?

Now it has. "What's new in VB 2005", read "Unsigned Types":
http://msdn.microsoft.com/en-us/library/y17w47af(VS.80).aspx

Its got a 8-bit and 16-bit unsigned type,
but no 32-bit unsigned.

Also, what are the units of the VB GetTickCount version?

It's not VB's version. It's a function in one of Windows' dlls (kernel32).

Again, in all
previous compilers it was in ms, is that still the case?

As it's the same function you use from different languages,
it is still ms.


And, BTW, have a look here:
http://msdn.microsoft.com/en-us/library/system.environment.tickcount.aspx

 

[Tom Shelton]

I know how to privately declare a function exported from kernel32.dll as
follows:
Private Declare Function GetTickCount Lib "kernel32 as Long

and then to use code like this:
Dim lElapsed as Long
lElapsed = (GetTickCount() - lPreviousTimeValue)
' etc

but I'm curious. Why is the type Long? The VB.NET (2003.NET) documentation
tells me that a Long is a 64-bit signed number. In my experience of all
previous compilers (Delphi 7, Visual C++, etc), I'ce always known
GetTickCount() to return a DWORD (unsigned 32-bit number).

In fact, the MSDN documentation states that:
DWORD WINAPI GetTickCount(void);
http://msdn.microsoft.com/en-us/library/ms724408(VS.85).aspx

Why does VB return a signed 64-bit number? Why doesn't VB have a unsigned
32-bit integer data type anyway? Its got a 8-bit and 16-bit unsigned type,
but no 32-bit unsigned.

Also, what are the units of the VB GetTickCount version? Again, in all
previous compilers it was in ms, is that still the case?

Thanks,
Alain

What Armin said... Plus, there is always System.Environment.TickCount which
internally calls GetTickCount anyway

 

[Alain Dekker]

Strange oversight not to include a unsigned integer as a native type in VB
2003.NET. I'll take the data type with the same bitness, thats fine.

Thanks for thoe replies!
Alain

 

[Patrice]

As a side not the declaration you used was likely for VB6. In VB6 long was
actually integer (likely because of its 16 bit past)... When picking a
"declare" somewhere double check if it was intended for VB6. In this case it
needs to be changed...

 

[Alain Dekker]

Aah yes good point. I have been trying to note the distinction when picking
up code off the internet, but sometimes the disctinction isbn't always clear
and sometimes it mayhave been copied from somewhere else (and not tested)
and its wrong.

I note, for example, that VB.NET now supports the C++ operator "+=" as in
nMyInteger += 3

which I'm pretty sure VB6 did not support.

 

[Armin Zingler]

Aah yes good point. I have been trying to note the distinction when picking
up code off the internet, but sometimes the disctinction isbn't always clear
[...]

Yep, this emphasizes my opinion that VB is still VB - even if not equal. :-D

 

[Chris Dunaway]

Because your declaration is wrong.


Yes, that's why the return value has to be UInteger (or UInt32)
in VB 2005/2008. In VB 2003, you were able to declare it as
Integer or Int32 which is at least the right bitness (32).

UInt32 was already there in FW 1.1:http://msdn.microsoft.com/en-us/library/hfa3fa08(VS.71).aspx
However, the type wasn't "CLS compliant", and VB 2003 didn't have
a mapped native type like UInteger yet.



Now it has. "What's new in VB 2005", read "Unsigned Types":http://msdn.microsoft.com/en-us/library/y17w47af(VS.80).aspx



It's not VB's version. It's a function in one of Windows' dlls (kernel32).


As it's the same function you use from different languages,
it is still ms.

And, BTW, have a look here:http://msdn.microsoft.com/en-us/library/system.environment.tickcount....

If you're ever in doubt about the signature of a api function, go to
pinvoke.net and you can find examples of most functions.

Chris

 

[mayayana]

Aah yes good point. I have been trying to note the distinction when
picking

up code off the internet, but sometimes the disctinction isbn't always clear
[...]

Yep, this emphasizes my opinion that VB is still VB - even if not equal. :-D

That's a somewhat odd conclusion. Someone
has run into problems because code websites
don't distinguish between two very different
things that are both called "VB". And you see
that as confirmation that "VB is VB".
Perhaps more interesting is the question of
why you feel a need for "VB to be VB".