Visual Basic .NET 2010 Express - What"s New With Visual Basic .NET Express
This is a free tutorial to help beginning programmers get up to speed using Microsoft Visual Basic 2010 Express. To get the most from this tutorial, you might want to start at the beginning. A complete index to the course is also in the front of the first lesson.
Part 1 - A "From the Ground Up" Tutorial - An introduction to the course.
VB6 and the Bad Old Days
Actually, those old days weren't that bad.
They were only "bad" in comparison to what's possible today using VB.NET. But there's one thing for certain: VB6 was a whole different world.
In fact, the main thing that is the same between VB6 and VB.NET is a language syntax similarity. I wrote an article about six of the "Top Five" Changes between VB6 and VB.NET. Why six? Well ... you'll just have to read the article to find out. (Hint: The debugging exercise at the end of this lesson illustrates the same idea.)
If I had to sum up the difference between VB.NET and VB6 in just one phrase, it would be: VB.NET gives you access to everything. Here's just one example just to demonstrate the point.
A VB.NET Event Subroutine
In VB6, the call to a button event subroutine looks like this:
In VB.NET, the same call has become:
What is all that extra stuff? Here's a very brief explanation.
The "extra stuff" in the .NET version is all information that was passed around behind the scenes in VB6.
Back then, you could never access it in your program. (Welllll ... If you were willing to code a lot of API calls to Windows system software, many things became possible, but the more you did that, the closer you got to the pain and suffering of C++.) VB is supposed to make it easy. API calls into Windows make it possible but they don't make it easy.
Sender is the software object which fired the event. In this case, it's System.Windows.Forms.Button. In VB6, 43 properties and 7 methods are available to your program for a Command component. Even Framework 3.5 gives you 94 properties, 51 methods, and 3 contained objects to use in your code. VB6 doesn't pass any event arguments to a Command subroutine, but the object e, a System.EventArgs "type", is passed with every event in VB.NET and this gives you the ability to write code that just wasn't possible in VB6.
If you're curious about how I know that the object System.Windows.Forms.Button was responsible for firing this object, you can place a breakpoint on the first excutable statement in the Button.Click event subroutine to suspend execution. Then run the program. Pause your mouse over Sender and the tooltip explanation will tell you. (Setting breakpoints is illustrated later in this lesson.)
The Handles clause is completely new in VB.NET and it's one of those things that was just not available before. Briefly, the Handles clause lets you specifically assign this subroutine to "handle" an event, like the click of a button.
VB.NET even gives you access to the system code where windows are drawn and controls are instantiated. (When a control is instantiated, a copy of the code for that control is created at runtime for use in your program.) In VB.NET 2010, this system code is in a separate object, objectname.Designer.vb to keep it "out of your way" as you're writing your code, but it's still completely accessible. I'll show you how to find it a little later.
If you really have the need, you can access the IL code that the VB.NET compiler (and all other .NET languages) produce. Microsoft provides the ILDASM program just for that purpose. (ILDASM is described in my article, The .NET Framework Tools - Introduction and ILDASM.)
There are two sides to all this new freedom and access, however. On the plus side is the fact that VB.NET is the equal of any other language now for whatever work you have to do. (I think that VB.NET is better because you can simply be more productive, but that's just my opinion.) On the minus side, this new freedom comes with new responsibilty and, yes, new complexity too. Because VB6 "protected" you from a system code, it was simplier and easier to use. VB.NET has a more difficult learning curve.
On the next page, we take a more detailed look at VB.NET Express and how it works.
Part 1 - A "From the Ground Up" Tutorial - An introduction to the course.
VB6 and the Bad Old Days
Actually, those old days weren't that bad.
They were only "bad" in comparison to what's possible today using VB.NET. But there's one thing for certain: VB6 was a whole different world.
In fact, the main thing that is the same between VB6 and VB.NET is a language syntax similarity. I wrote an article about six of the "Top Five" Changes between VB6 and VB.NET. Why six? Well ... you'll just have to read the article to find out. (Hint: The debugging exercise at the end of this lesson illustrates the same idea.)
If I had to sum up the difference between VB.NET and VB6 in just one phrase, it would be: VB.NET gives you access to everything. Here's just one example just to demonstrate the point.
A VB.NET Event Subroutine
In VB6, the call to a button event subroutine looks like this:
Private Sub Command1_Click()In VB.NET, the same call has become:
Private Sub Button1_Click(ByVal sender As System.Object,ByVal e As System.EventArgs) Handles Button1.ClickWhat is all that extra stuff? Here's a very brief explanation.
The "extra stuff" in the .NET version is all information that was passed around behind the scenes in VB6.
Back then, you could never access it in your program. (Welllll ... If you were willing to code a lot of API calls to Windows system software, many things became possible, but the more you did that, the closer you got to the pain and suffering of C++.) VB is supposed to make it easy. API calls into Windows make it possible but they don't make it easy.
Sender is the software object which fired the event. In this case, it's System.Windows.Forms.Button. In VB6, 43 properties and 7 methods are available to your program for a Command component. Even Framework 3.5 gives you 94 properties, 51 methods, and 3 contained objects to use in your code. VB6 doesn't pass any event arguments to a Command subroutine, but the object e, a System.EventArgs "type", is passed with every event in VB.NET and this gives you the ability to write code that just wasn't possible in VB6.
If you're curious about how I know that the object System.Windows.Forms.Button was responsible for firing this object, you can place a breakpoint on the first excutable statement in the Button.Click event subroutine to suspend execution. Then run the program. Pause your mouse over Sender and the tooltip explanation will tell you. (Setting breakpoints is illustrated later in this lesson.)
The Handles clause is completely new in VB.NET and it's one of those things that was just not available before. Briefly, the Handles clause lets you specifically assign this subroutine to "handle" an event, like the click of a button.
VB.NET even gives you access to the system code where windows are drawn and controls are instantiated. (When a control is instantiated, a copy of the code for that control is created at runtime for use in your program.) In VB.NET 2010, this system code is in a separate object, objectname.Designer.vb to keep it "out of your way" as you're writing your code, but it's still completely accessible. I'll show you how to find it a little later.
If you really have the need, you can access the IL code that the VB.NET compiler (and all other .NET languages) produce. Microsoft provides the ILDASM program just for that purpose. (ILDASM is described in my article, The .NET Framework Tools - Introduction and ILDASM.)
There are two sides to all this new freedom and access, however. On the plus side is the fact that VB.NET is the equal of any other language now for whatever work you have to do. (I think that VB.NET is better because you can simply be more productive, but that's just my opinion.) On the minus side, this new freedom comes with new responsibilty and, yes, new complexity too. Because VB6 "protected" you from a system code, it was simplier and easier to use. VB.NET has a more difficult learning curve.
On the next page, we take a more detailed look at VB.NET Express and how it works.
