The Top Five Changes between VB 6 and VB.NET

By Dan Mabbutt

1 of 8

The Top Five Changes between VB 6 and VB.NET

Updated October 16, 2015.

Visual Basic 1.0 was a major earthquake throughout programming. Before VB1, you had to use C, C++, or some other horrible development environment to create Windows applications. Programmers literally spent weeks just drawing windows on screens with picky, detailed, hard to debug code. (The same thing you can do by dragging a form from the toolbar in a few seconds.) VB1 was a hit and gazillions of programmers immediately started using it.

But to make the magic happen, Microsoft made some major architecture compromises. In particular, since VB1 created the forms and controls, they didn't allow the programmer access to the code that did it. You either let VB create everything, or you used C++.

VB 2 through 6 maintained this same architecture. Microsoft made some very clever updates which gave programmers a lot more control, but in the final analysis programmers still couldn't integrate their code with the VB code. It was a black box - and not in the good OOP way either. Another way of saying this was that the programmer didn't have access to the internal VB "objects" and another way of saying that was that VB6 still wasn't fully "object oriented".

Show All

2 of 8

VB 6 - Falling Behind the Technology Curve

In the meantime, Java, Python, and a whole lot of other programming languages that WERE object oriented started to appear. Visual Basic was getting passed up - big time! This is a situation Microsoft does not tolerate ... and they resolved to solve the problem once and for all. The solution is .NET.

But to do the things that .NET needed to do, Microsoft decided that they had to "break compatibility".

That is, Visual Basic programs had been (with very minor exceptions) "upward compatible" from VB1 right up to VB6. A program written in that first version of VB would still compile and run in the next version. But with VB.NET, Microsoft found they just couldn't make the language completely OOP and maintain upward compatibily.

Once they made this fundamental decision, the flood gates opened on ten years of accumulated "wish list" changes and ALL of them went into the new VB.NET. As they say in Britain, "In for a penny, in for a pound."

Without further delay, here's my very personal list of the top five changes from VB6 to VB.NET in reverse order.

Wellllll .... just one further delay. Since we're changing from VB6, where an array declared as Dim myArray(5) has 6 elements, We have six of 'em. It's only fitting ...

(Drum roll please ...)

Show All

3 of 8

Award(5) - C-like Syntax Changes

"Award(5)", our 6th Place award goes to the C groupies choice: C-like Syntax Changes!

Now you can code a += 1 instead of a = a + 1, saving THREE WHOLE KEYSTROKES!

Programmers of the World, Rejoice! VB has been raised up to C level, and a whole new generation trying to learn VB will get a little closer to the mass confusion that confronts students of C++.

But wait! There's more!

VB.NET now features "short circuit logic" that has introduced subtle bugs into C++ code for years to save precious nano-seconds of processor time.

Short circuit logic only evaluates multiple conditions in a logical statement if necessary. For example:

Dim R As Boolean
R = Function1() And Function2()

In VB6, both functions are evaluated whether they need it or not. With VB.NET, if Function1() is false, Function2() is ignored since "R" can't be True. But, what if a global variable is changed in Function2() - just by chance (C++ programmers would say, "by poor programming".) Why does my code produce the wrong answer some of the time when it's translated to VB.NET? This might be it!

For Trying harder, VB.NET will Catch a little luck and Finally get recognized for "exceptional" error handling.

VB6 had the last holdout GoTo: "On Error GoTo". Even I have to admit that the C++ style "Try-Catch-Finally" structured exception handling is a vast improvement, not just a half vast improvement.

What, you say "On Error GoTo" is still in VB.NET? Wellll ... We try not to talk about that too much.

Show All

4 of 8

5th Place - The Miscellaneous Command Changes

5th Place selection is a group award: The Miscellaneous Command Changes! They have to share this award and there's a gazillion of 'em. Microsoft has been saving up for ten years and they really cut loose.

VB.NET no longer supports VarPtr, ObjPtr and StrPtr functions which retrieved the memory address of variables. And it doesn't support VB6 LSet which was used to convert one user defined type to another.

(Not to be confused with VB6 LSet which does something completely different - see below.)

We also bid fond adieu to Let, Is Missing, DefBool, DefByte, DefLng, DefCur, DefSng, DefDbl, DefDec, DefDate, DefStr, DefObj, DefVar, and (my personal favorite!) GoSub.

Circle has morphed into GDI+ DrawEllipse. The same goes for Line to DrawLine. In calculation we now have Atan instead of Atn, Sign goes in for Sgn, and Sqrt suits up for the big game instead of Sqr.

In string processing, even though they're still available if you reference a Microsoft compatibility namespace, we have PadRight for VB6's LSet (again, totally different than VB6's LSet, of course) and PadLeft for RSet. (There goes the three keystrokes we saved with "+="!)

And of course, since we're OOP now, don't fret if Property Set, Property Let, and Property Get are not met in VB.NET, you bet!

Finally, Debug.Print becomes either Debug.Write or Debug.WriteLine. Only nerds print everything anyway.

This doesn't even touch all the NEW commands in VB.NET, but we've got to stop this nonsense somewhere.

Show All

5 of 8

4th Place - Changes to Procedure Calls

In 4th Place, we have Changes to Procedure Calls!

This is the "goodness, purity, and wholesome virtue" award and represents a lot of hard campaigning by the "no more sloppy code" faction.

In VB6, if a procedure parameter variable is an intrinsic type, then it's ByRef, unless you have coded it ByVal explicitly, but if it's not coded ByRef or ByVal and it's not an intrinsic variable then it's ByVal. ...

Got that?

In VB.NET, it's ByVal unless it's coded ByRef.

The ByVal VB.NET default, by the way, also prevents changes to parameter variables in procedures from being unintentionally propagated back into the calling code - a key part of good OOP programming.

Microsoft also "overloads" VB.NET with a change in the requirements for parentheses in procedure calls.

In VB6, parentheses are required around arguments when making function calls, but not when calling a subroutine when not using the Call statement but they are required when the Call statement is used.

In VB.NET, parentheses are always required around a nonempty argument list.

Show All

6 of 8

3rd Place - Arrays are 0 based instead of 1 based

The Bronze Award - 3rd Place, goes to Arrays are 0 based instead of 1 based!

It's just one syntax change, but this change gets "medal podium" status because it is voted, "most likely to screw up your program logic". Remember, 3rd place IS "Award(2)" in our list. If you have counters and arrays in your VB6 program (and how many don't), this one will MESS YOU UP.

For ten years, People have been asking, "What was Microsoft smoking when they did it this way?" And for ten years, programmers have sort of universally ignored the fact that there was a myArray(0) element that just took up space and didn't get used for anything ...

Except for those programmers who DID use it and their programs looked, I mean, just "weird".

For I = 1 to 5
MyArray(I - 1) = Whatever
Next

I mean, REALLY! ...

Show All

7 of 8

2nd Place - The Variant Datatype

The Silver Medal of 2nd Place goes to honor an old friend that was dropped into the bit bucket of programming with the passing of VB6! I speak of none other than, The Variant Datatype.

Probably no other single feature of Visual Basic "notNet" better represents the philosophy of "fast, cheap, and loose". This image dogged VB right up to the introduction of VB.NET. I'm old enough to remember the introduction of Visual Basic 3.0 by Microsoft: "Oh Wow!

Lookee here! With the new, improved Variant data type, you don't have to declare variables or nothin'. You can just think 'em up and code 'em."

Microsoft changed their tune pretty fast on that one and recommended declaring variables with a specific datatype almost immediately, leaving many of us to wonder, "If you can't use Variants, why have them?"

But while we're on the subject of datatypes, I should mention that a lot of datatypes have changed in addition to dropping Variant into wet cement. There's a new Char datatype and a Long datatype that is 64 bits. Decimal is way different. Short and Integer aren't the same length anymore.

And there is a new "Object" datatype that can be anything. Did I hear someone say, "Son of Variant"?

Show All

8 of 8

1st Place - VB.NET is finally completely Object Oriented

Finally! The Gold Medal, 1st Place, the highest award I can bestow goes to ...

TA DAH!

VB.NET is finally completely Object Oriented!

Now when you go to the beach, the C++ programmers won't kick sand in your face and steal your (girlfriend/boyfriend - pick one). And you can still code a complete General Ledger Trial Balance while they're trying to figure out which header files to include.

For the first time, you can code as close to the chip as you need to and access all the system internals your heart desires without having to resort to those nasty Win32 API calls.

You've got inheritance, function overloading, asynchronous multithreading, garbage collection, and everything is an object. Can life get any better?