VB.Net is Easy!

Introduction

Over the last few years since .Net came out, there has been a lot of myths and superstition about the Visual Basic.Net programming language. We were all warned up front that things were changing. The new version of VB was not the same as the old one and there would be a learning curve. It seems that everyone from hobbyist programmers to editors of programming magazines (i.e. Visual Studio Magazine) began complaining that VB.Net was too hard, that there should be an ‘easier’ version, that Microsoft sold us out by changing VB, even recently that VB needs a new name. I recently saw that some people are trying to organize and petition Microsoft to continue support for VB6.

As I made the switch from VB6 to VB.Net, wrote applications in the new version, and even taught a class in VB.Net, I realized that the rationale behind all the fear and complaints is simply wrong. So here in this article I will show you the truth; that VB.Net is not only a better programming language and environment than VB6 but it is actually easier! I will also make the case that if you like Visual Basic and want to keep it alive, you had better get on the .Net bandwagon, or you will end up having to write everything in languages that are littered with curly braces and semicolons.

A Little History

Visual Basic 6.0 came out in 1998. It was the culmination of a revolutionary platform for programming rich Windows applications visually. Anyone who has ever written a GUI app. in C++ for Windows or Unix or at least seen the code, understands why I would use the word revolutionary. With Visual Basic you could visually design your form, drag and drop controls on the form, and write event-driven code that concentrated on the functionality of your application, versus the mechanics of the form itself. And the language was familiar to many self-taught and amateur programmers, and less cryptic than more industrial languages like C++.

While the language evolved some as VB was enhanced, the platform stayed essentially the same. By 2000, the visual elements in VB looked out of date, and programming methodologies (e.g. Object-Oriented) had evolved well beyond the capabilities of the Visual Basic language. To be sure, VB was a huge success. It found its way into the business world and had a great run there. I think this was because of the high level of productivity obtained by VB programmers and the relative ease of application maintenance. We accomplished much with a supposedly inferior language. But in order to keep up with the programming world, and provide the power that developers wanted, things had to change.

They knew going in that making huge changes to VB was risky. Although quieter and less zealous than other computer related groups, the VB fan base is huge and loyal. Selling them on the new version would be difficult. If you count yourself in this club, then you are the person I want to talk to. So without any further bla-bla, here is the truth about VB.Net.

Forms

Explorer Form

A Windows application (i.e. Forms Application) is where most people start when they are learning VB. Windows applications sort of got a bad rap in recent years because of deployment issues, and the prevalence of the web. But they are set to make a huge come-back with .Net Smart Client technology.

We did a lot of great things with VB6 forms. But very often we also had to rig things and use tricks to get what we wanted. Wouldn’t it be nice to get rid of some of the issues that were a pain and caused a lot of extra code? Believe it or not, Microsoft listened and did some of that with forms in .Net.

Figure 1. Explorer Type Form

Look at Figure 1. This is a classic example of an explorer type form. It has a Treeview on the left, and typically a Listview on the right. I used a text box in the sample app for simplicity. The user is able to resize the form and adjust the proportion of the form taken up by the two major controls. The controls must respond in an expected way no matter how the user adjusts the form.

How would you do this in VB6? Well first, you would have to obtain a copy of the correct common controls ActiveX controls in order to use the Treeview and Listview. You know the hassles that brings with versioning. You would also have to obtain a splitter control or roll one of your own. And you would have to write code to make sure resizing and adjusting the split worked.

• In .Net, all the common controls are built in. Treeview, Listview, Status Bar, etc. They are just there; you don’t have to use outside controls.
• Using docking and anchoring in .Net forms, you can layout controls that automatically adjust size and/or position when the user resizes the form with NO CODE!
• The splitter is used in conjunction with docked controls to allow the user to adjust the relative size of the controls. With NO CODE!

That’s right; the form depicted here has this functionality with no user code added. The only code in the sample is for handling clicks on the TreeView. How many lines of code would it take in VB6 to accomplish this? When you try this in .Net you see that it is easier than in VB6.

Dialog Form

Figure 2. Dialog Box Form

Another common task in forms programming is the dialog box. This is a form that once opened, must be cleared by the user before they can access the calling application. We typically need to know how the user did this; did they hit OK or Cancel? Figure 2 is a simple dialog box. The form’s control box is not shown, and there are OK and Cancel buttons, both of which close the form.

• .Net forms have AcceptButton and CancelButton properties that allow you to set which buttons act as the OK (Accept) button and the Cancel button.
• The forms ShowDialog method returns an enumeration that easily indicates which action was taken on the dialog form by the user.
• The button controls have DialogResult property that allows you to set which result is returned when the button is clicked.

The combination of these features allows you to design this form with… you guessed it, NO CODE. Easier than VB6!

Events and Control Array

Figure 3. Events Form

One of the objections I hear about VB.Net forms is that they took away control arrays. But the reason we had them to begin with was to deal with limitations in the event handling mechanisms. These events are lifted in .Net. Figure 3 shows a form with a set of buttons, all of which do the same thing; they add their numeral to the text in the text box.

• In the .Net framework event handler procedures can handle events from more than one control. Also, a controls event can be handled by more than one handler. So a control array is not necessary. There are a couple of easy ways you can tell your application to use one routine to handle all button clicks.

Of course if you really, really want to use a control array you can find them in the Visual Basic compatibility objects included in .Net. So they aren’t completely gone.

Object Oriented Programming

I think some people are afraid to jump into .Net because they have heard that the whole thing is object oriented and you have to change the way you write code to do it in .Net. I could do a whole article on why you should learn object oriented programming, (starting with “it’s not that hard”) but I don’t need to do that here.

If you want to have applications where you double-click on form controls and write code in event handlers in the form, and have utility functions in a module, you can still do that. You can pretty much write old-fashioned VB code the way you always did and it will still compile and run in .Net. Now behind the scenes, the compiler will make modules into classes with all your public functions as shared functions. But if you don’t know what that even means, it doesn’t matter.

If you have been using classes in VB6, you are already half the way there to object oriented programming. The big thing you want to learn about is inheritance. I thought that was a difficult subject in the past, but since I taught the basic concept in the first VB.Net class in the sequence (at UCSD Extension) I realized that it's not that bad. There are complexities to object oriented programming, but the fundamental concepts aren’t difficult, and once you get them, you will find that you can write much more organized and less repetitive code.

• The point is, you can continue to code the way you always did with event-based routines and utility functions. As you learn new techniques, you can then add them into the way you write code.

.Net Framework

I also hear that people are intimidated by having to learn all of the hundreds or thousands of objects in the .Net framework. Well who said you have to learn them all? It’s true there are a gazillion objects shipped with .Net. Some of them are amazing things that allow you to do things that were extremely difficult or impossible in VB6. I won’t say that you will never have to do an API call again, but many things you had to do with the API are just there now. Want to make your application multi-threaded, talk on a socket, examine classes in other .dlls, encrypt data, manipulate images, etc.? There are classes in the .Net framework for you. You might be surprised to find that they aren’t as difficult as you thought.

But without getting in to all that advanced stuff…

• The objects you used in VB6 have descendents in .Net that are very similar in their function and use. You will be able to learn them and move on in no time. A text box is still fundamentally, a text box.

When you are ready, there are some objects that are easy to learn and use, and will make a tremendous difference in the performance of your application. Two that you should look at are the StringBuilder and the Hashtable. I use them all the time.

And speaking of API calls. You know what happens if you blow an API call in VB6 don’t you? Not only your program crashes, but VB itself will likely disappear without a trace. The whole way API calls are handled in .Net is much better. I can’t say they are without hazard, but debugging them is certainly more controlled than before.

Upgrading

I saw a comment recently from someone who was bemoaning the demise of VB6. This person said that they didn’t want to let go of VB6 because they couldn’t upgrade the code and would have to rewrite it all in .Net. Uh, well, that is simply not true. Microsoft went to great lengths to provide a solution for that person. There is a whole set of .Net framework classes that comprise a VB6 compatibility layer. There is also a good upgrade wizard. When you run this wizard, it will create a .Net project with your VB6 code fixed up to run with the compatibility layer. I don’t think it will get everything, but it’s pretty good. Any further fixing up you have to do will be far less than ‘rewriting’.

Now this upgraded program isn’t optimal. It won't be using all the best .Net objects, error handling or ADO.Net. It will be using some objects from the compatibility layer. Yes indeed, if you want an optimal program, you will end up redoing it with normal .Net objects. But the point is you don’t have to.

And you don’t even really have to upgrade right away. You can use COM .dlls and ActiveX controls in .Net applications. There is an interop. layer that is required, but Visual Studio makes this for you when you set a reference. So if you have a lot of business logic wrapped up in VB6 classes, you can continue to use them now, and recode them in .Net later.

If you use third-party ActiveX controls such as grids, you can use them on your .Net forms. The makers of these controls are now selling upgraded versions that are native .Net controls, in case you are ready to upgrade them.

So to wrap this up…

• You can upgrade your VB6 code with help from Visual Studio.Net. But you don’t have to, you can use your previous components in .Net and you can use new .Net components within COM/VB6 apps. Although you will want to rewrite your code eventually, it is not necessary to begin to use .Net

Deployment

Hopefully there aren’t any myths to dispel here. It has been very well documented that .Net applications are easier to deploy than COM applications. I just wanted to mention it because it’s another reason that .Net is easier than VB6. No more .dll hell.

Visual Studio

Visual Studio 6 was not an integrated product. You are aware of this if you also did Visual C++ or classic ASP programming. The VB6 editor only did VB, and in ASP, you were only using VB Script, not the full language. In .Net it is completely integrated. Any language, any type of application. You should be able to leverage your VB programming skills and code no matter whether you are doing a Windows app., an ASP.Net app., or an app. that targets compact devices. In .Net, you can.

I have used many code editors over the years, and I can say that VS.Net is the Cadillac of IDEs. Things like Intellisense and code completion were there before, but are much more complete in .Net. Code formatting? Again, it’s easier in .Net because it does it for you.

• A very important point to understand is that the language (and framework) are decoupled from the editor. Don’t want to pay for Visual Studio? You can download the .Net SDK for free. That’s right, .Net is free! Microsoft also provides lightweight FREE versions of Visual Studio you can download - Visual Studio Express. You can also download a free open source IDE. Or you write your code in any text editor and use command line compiler commands.

One big bummer that VB people had to live with in .Net is that you can’t edit-and-continue. The only reason you ever could in VB before is because it started life as an interpreted language, and that was still built in the editor. Visual Studio 2005 fixed that problem, so now there really is no excuse!

If You Like VB, Keep It Alive

It may be that the biggest problem with VB is C#. Microsoft introduced a new language with .Net and publicized it heavily. Many people jumped on the C# language bandwagon, faster and more loudly than with VB converts. There are some pervasive myths running around that C# is somehow better or more professional than VB. But the truth is that they compile to the same .Net framework. More and more of the work in your program is going to be done by .Net objects that are the same no matter which language you use. Microsoft themselves say that there are not performance differences, providing that you follow some guidelines to make sure your code can be compared fairly (Look Here) VB.Net is a full featured language that can stand on par with any professional language.

Nevertheless, C# has a lot of momentum. Most advanced .Net programming classes and seminars I see are in C#. Most job ads I have seen lately for .Net programmers list C# as a requirement. C# pulled out ahead of VB in part because VB programmers have been very slow to adopt .Net. It makes me wonder what kind of future VB has in the long run. Why should Microsoft keep working on VB if everyone starts using C#?

I believe if you like VB, you need to get going in .Net now. The reason why Microsoft would keep going with VB is because there are legions of developers who want it. There are new features in 2005 release that are designed to try to attract more VB6 users to convert. I think you should take a look at them. Start now and get yourself going with .Net. There will always be new things to learn. VB6 is history, and I would rather see you invest your time and energy in the future and help make VB.Net the language you want, rather than try to hold back time.

The Challenge

I’ve tried to give you some reasons to look at VB.Net and overcome some of the objections that have been made. If you are skeptical, I understand. But take a look.  I believe that once you see the power and flexibility of the .Net framework and VB.Net you won’t want to go back.