Upgrading to VB.Net

  • Thread starter Thread starter Robert
  • Start date Start date
R

Robert

The following snippet is my code from a VB6.0 Module.
I am now using Visual Studio 2008 Standard.

'Registry Constants

Public Const HKEY_CLASSES_ROOT = &H80000000

Public Const HKEY_CURRENT_USER = &H80000001

Public Const HKEY_LOCAL_MACHINE = &H80000002

Public Const HKEY_USERS = &H80000003

I have created a VB.Net app, and when I place the above in a Module it has
blue squiggly lines stating that it must be declared

with an "AS"

Can some one help with my upgrading of my code.

What is the .Net version of the above.

Also, now the following does not work in .Net.

Type SECURITY_ATTRIBUTES

nLength As Long

lpSecurityDescriptor As Long

bInheritHandle As Boolean

End Type

Any sites with tutorials for upgrade code to .Net.
 
Public Const HKEY_CLASSES_ROOT as Long = &H80000000 ?


I would google "Option Strict On" and "Option Explicit On".

Do NOT Turn them off...learn what they mean.
 
Hi Robert

Well, there are multiple facets to this.

For starters, any time you declare a constant (or any variable) it needs to
have a type declaration. So in this example, it should be:

Public Const HKEY_CLASSES_ROOT As Integer = &H800000

(note the "As Integer" type declaration).

Secondly, this is clearly code you're using to call the registry API, but
there's no need - the .NET Framework has all of that built in, so you don't
need to use interop for it. Unlike VB6.0 you get direct access to any hive
in the registry rather than being restricted to HKCU\Software\Microsoft\VB &
VBA (or something)\YourApp.

Check out the Microsoft.Win32.Registry namespace, and with a bit of digging
in the documentation you'll be doing it all through .NET classes with no
interop needed.

Enjoy using .NET :-)

Alex
 
Thanks for the info.
Will start to learn this.

Alex Clark said:
Hi Robert

Well, there are multiple facets to this.

For starters, any time you declare a constant (or any variable) it needs
to have a type declaration. So in this example, it should be:

Public Const HKEY_CLASSES_ROOT As Integer = &H800000

(note the "As Integer" type declaration).

Secondly, this is clearly code you're using to call the registry API, but
there's no need - the .NET Framework has all of that built in, so you
don't need to use interop for it. Unlike VB6.0 you get direct access to
any hive in the registry rather than being restricted to
HKCU\Software\Microsoft\VB & VBA (or something)\YourApp.

Check out the Microsoft.Win32.Registry namespace, and with a bit of
digging in the documentation you'll be doing it all through .NET classes
with no interop needed.

Enjoy using .NET :-)

Alex
Click to expand...
 
Robert said:
The following snippet is my code from a VB6.0 Module.
I am now using Visual Studio 2008 Standard.

'Registry Constants

Public Const HKEY_CLASSES_ROOT = &H80000000

Public Const HKEY_CURRENT_USER = &H80000001

Public Const HKEY_LOCAL_MACHINE = &H80000002

Public Const HKEY_USERS = &H80000003

I have created a VB.Net app, and when I place the above in a Module it has
blue squiggly lines stating that it must be declared

with an "AS"

Can some one help with my upgrading of my code.

What is the .Net version of the above.
Click to expand...

Public Const HKEY_CLASSES_ROOT As Integer = &H80000000
Public Const HKEY_CURRENT_USER As Integer = &H80000001
Public Const HKEY_LOCAL_MACHINE As Integer = &H80000002
Public Const HKEY_USERS As Integer = &H80000003
Also, now the following does not work in .Net.

Type SECURITY_ATTRIBUTES

nLength As Long

lpSecurityDescriptor As Long

bInheritHandle As Boolean

End Type
Click to expand...

You use a class:

Class SecurityAttributes

Public Length As Integer
Public SecurityDescriptfor As Integer
Public InheritHandle As Boolean

End Class
Any sites with tutorials for upgrade code to .Net.
Click to expand...

I found a few googling...

Upgrading VB6 to VB.NET
http://www.codeproject.com/KB/vb/VB6ToVBNET.aspx

Upgrading Visual Basic 6.0 Applications to Visual Basic .NET and Visual
Basic 2005:
http://msdn.microsoft.com/en-us/library/aa480541.aspx

The VB.NET Upgrade Wizard
http://visualbasic.about.com/od/imhoinmyhumbleopinion/l/aa120102a.htm

Making the transition from VB6 to VB.NET
http://articles.techrepublic.com.com/5100-10878_11-1049893.html
 
Robert,

Be aware that to describe a 32 bit integer in fact the Int32 is better.

The Integer is a pseudo code for an Int16 on 16bit based processors software
(vb6) and Int32 on 32bit processor based computers.
To make it real confusing is an Integer for 64 based computer still an
Int32,
Not a decission from Microsoft but from some influenced customers
(Processing of a programword takes in those computers forever an extra
step).

Cor
 
Cor said:
Robert,

Be aware that to describe a 32 bit integer in fact the Int32 is better.

The Integer is a pseudo code for an Int16 on 16bit based processors
software (vb6) and Int32 on 32bit processor based computers.
Click to expand...

What are you talking about? VB Has been 32-bit since VB4 and Windows 95.

The Integer data type does not change depending on the platform. The
Integer data type in VB6 is 16 bits and the Integer in VB.NET is 32 bits.
To make it real confusing is an Integer for 64 based computer still an
Int32,
Click to expand...

Hardly confusing as the size of the data type doesn't depend on the
platform. The Integer data type in VB.NET corresponds to the CLR data
type Int32, and making the Int32 data type 64 bits is something that
would actually be confusing.
 
Göran Andersson said:
What are you talking about? VB Has been 32-bit since VB4 and Windows
95.
Click to expand...

I guess Cor meant that VB6's Integer data type was still a relict from the
16 bit OSes and machines. I'd agree.
The Integer data type does not change depending on the platform. The
Integer data type in VB6 is 16 bits and the Integer in VB.NET is 32
bits.

Hardly confusing as the size of the data type doesn't depend on the
platform. The Integer data type in VB.NET corresponds to the CLR data
type Int32, and making the Int32 data type 64 bits is something that
would actually be confusing.
Click to expand...

True, but the reason for the change of the integer type from 16 to 32
bits was due to the change of the plattforms in the course of time.
Even though the latest plattform is 64 bit, Integer is still 32 bit.
That's how I read Cor's reply - and I'd agree again. :)


Armin
 
Armin said:
I guess Cor meant that VB6's Integer data type was still a relict from the
16 bit OSes and machines. I'd agree.
Click to expand...

Yes, of course, but he says that it's because Integer is a psuedo code,
and that VB6 produces 16 bit programs. Do you agree with that too?
 
Göran Andersson said:
Yes, of course, but he says that it's because Integer is a psuedo
code, and that VB6 produces 16 bit programs. Do you agree with that
too?
Click to expand...

My turn to guess! I reckon that "Integer" once upon a time corresponded to
the processor's word size, as opposed to explicitly stating the size of an
integer, e.g. Int16, Int32, etc. However, with the current mix of 32- and
64-bit processors/OSen, those people used to typing Integer instead of
explicitly stating the size of the integer to be used would keep bumping
into lots of annoying discrepancies, so "Integer" is now used to mean Int32,
regardless of the processor's word size.

Andrew
 
However, with the current mix of 32- and 64-bit processors/OSen, those
people used to typing Integer instead of explicitly stating the size of the
integer to be used would keep bumping into lots of annoying discrepancies,
so "Integer" is now used to mean Int32, regardless of the processor's word
size.
Click to expand...

(with Net software)

Keeping the integer size the same as the register size was to get the
maximum performance in a program without that you had to rewrite your
program completely. Now it means to get the maximum performance on a 64bit
computer you have in fact to rewrite your program.

The argument to not make the integer the same as the register size as in
64bits environment was, that because the computers are today fast enough.
However the perfomance from a punchcard computer to a diskcomputer has been
much more and in those days this argument would been seen as complete
amaturisme.

jmo

Cor
 
Göran Andersson said:
Yes, of course, but he says that it's because Integer is a psuedo
code, and that VB6 produces 16 bit programs. Do you agree with that
too?
Click to expand...

Agree to the statement or that Cor said it? :) I agree that Integer was a
"pseudo code" for "native integer" even with VB6 that produced 32 bit
applications (whatever that is...). And I agree that this is not true
anymore (that's the "confusing" part).


Armin
 
Andrew said:
My turn to guess! I reckon that "Integer" once upon a time corresponded to
the processor's word size, as opposed to explicitly stating the size of an
integer, e.g. Int16, Int32, etc. However, with the current mix of 32- and
64-bit processors/OSen, those people used to typing Integer instead of
explicitly stating the size of the integer to be used would keep bumping
into lots of annoying discrepancies, so "Integer" is now used to mean Int32,
regardless of the processor's word size.

Andrew
Click to expand...

Yes, that is pretty accurate, however it has never applied to VB.

The int type in the C language (for example) was loosely defined so that
it could use the word size of the current platform, which was intended
to keep the language future proof. However, the practical life time of a
specific dialect of a programming language is rarely so long that it is
a problem, and many programs rely on a specific size of the data type so
they can't just be recompiled for a new platform without modifications
anyway.

The Integer type in VB has never had this loose definition, it has
always been a specific size. The definition of Integer changed from VB6
to VB.NET, but that doesn't mean that the definition is platform
dependend, it only means that they are separate definitions.
 
Cor said:
(with Net software)

Keeping the integer size the same as the register size was to get the
maximum performance in a program without that you had to rewrite your
program completely. Now it means to get the maximum performance on a
64bit computer you have in fact to rewrite your program.
Click to expand...

No, you don't have to rewrite the program. I have tested this, and Int32
is still the fastest data type even on an x64 platform.

Most performant integers for x86:
1. Int32
2. Int16
3. Int64, Byte

Most performant integers for x64:
1. Int32
2. Int64
3. Int16, Byte

So, if the Integer data type would have depended on the word size, the
same program would actually run slower as a 64 bit application than as a
32 bit application.
 
Armin said:
Agree to the statement or that Cor said it? :) I agree that Integer was
a "pseudo code" for "native integer" even with VB6 that produced 32 bit
applications (whatever that is...).
Click to expand...

An Integer in VB6 is 16 bits while the "native integer" (machine word)
is 32 bits. How do you mean that the Integer type is a "pseudo code" for
the "native integer"?
And I agree that this is not true
anymore (that's the "confusing" part).
Click to expand...

As it was never true, how is it confusing that it's not true now? ;)
 
Göran Andersson said:
An Integer in VB6 is 16 bits while the "native integer" (machine word)
is 32 bits. How do you mean that the Integer type is a "pseudo code"
for the "native integer"?
Click to expand...

Yes, now it's 32 bits, but VB6' Integer has been inherited from previous
versions when it was a native integer on 16 bit machines.

I'm not talking about documented, platform specific types like we have with
IntPtr now. I mean, it has not been documented anywhere that "Integer is the
platform specific integer type", but it was the type commonly used for
integer operations and it "happened to" match the native integer size.
As it was never true, how is it confusing that it's not true now? ;)
Click to expand...

I think it was true.

Anyway, who actually cares? ;-)


Armin
 
Unlike VB6.0 you get direct
access to any hive in the registry rather than being restricted to
HKCU\Software\Microsoft\VB & VBA (or something)\YourApp.
Click to expand...

This is incorrect - VB6 does not have this restriction.
 
Armin said:
Yes, now it's 32 bits, but VB6' Integer has been inherited from previous
versions when it was a native integer on 16 bit machines.
Click to expand...

No, it never was a native integer.
I'm not talking about documented, platform specific types like we have
with IntPtr now. I mean, it has not been documented anywhere that
"Integer is the platform specific integer type", but it was the type
commonly used for integer operations and it "happened to" match the
native integer size.
Click to expand...

That's my point, it once was picked to be the same size as the current
machine word, but it has never been depending on the actual size of the
machine word.
I think it was true.
Click to expand...

If it was once true, it would be true now also, which it clearly isn't.

Besides, if it's not confusing with a 16 bit Integer on a 32 bit
platform, how can it be confusing with a 32 bit Integer on a 64 bit
platform?
Anyway, who actually cares? ;-)
Click to expand...

Well, I care because I don't want too much misinformation floating
around. Cor clearly stated that an Integer is 16 bits on a 16 bit
platform and 32 bits on a 32 bit platform, and that is a connection that
doesn't exist at all. He also said that VB6 produces 16 bit software,
which it never has.
 
Yes, it does:

http://support.microsoft.com/kb/250673

Note that this applies to VB5 & VB6 according to the documentation, and
clearly states that GetSetting/SaveSetting write to
"HKEY_CURRENT_USER\Software\VB and VBA Program Settings".

MS never removed the restriction prior to .NET.


-Alex
 
Göran Andersson said:
Well, I care because I don't want too much misinformation floating
around. Cor clearly stated that an Integer is 16 bits on a 16 bit
platform and 32 bits on a 32 bit platform, and that is a connection
that doesn't exist at all. He also said that VB6 produces 16 bit
software, which it never has.
Click to expand...

I won't comment or interpret Cor's statement again. He can answer on his
own.


Armin
 
Back
Top