|
his month finds me in a nostalgic mood. It was about 10 years ago that I received a package from Microsoft containing the first version of Visual Basic®—a product that at the time had received little attention in the industry. In fact, the large software manufacturer that I was working with went to great lengths to downplay Visual Basic and what it could be used for. Today, however, Visual Basic is thriving.
I remember opening the box and installing Visual Basic 1.0. I tried to develop a small application with it, but I was frustrated. So, I uninstalled it and put the box back on the shelf. At the time, I had programmed in about 12 different languages and Visual Basic simply didn't feel right. Ah, well.
About two weeks later, I decided to look at Visual Basic again. I reinstalled it and spent a good bit of time looking at how it worked, how it could be used to build applications, and how fast it would be to create applications with it. After a few hours, I was hooked and have rarely programmed in anything else since.
The features of Visual Basic that intrigued me were its event-based programming model and the Toolbox. Event-based programming took a while for most developers to grasp. Once you discovered that you could simply place a line or two of code inside the event handlers and you had a functioning application, events really began to make sense and you could easily shift into the new development paradigm. It's going to feel like déjà vu with Visual Basic .NET and Web applications. But more on that later.
It can be argued that the Toolbox is the key to development with Visual Basic and of its success in the marketplace. The Toolbox provided lots of amazing little widgets for building applications. For example, drawing a textbox on a form with a simple drag and drop seemed like magic. The Toolbox was expandable, too. For a small fee, you could buy .vbx controls to perform all types of actions. Development hasn't been the same since.
The only thing I found missing from Visual Basic 1.0 was some type of hook to a database. As some of you will remember, there wasn't a single word about databases in the accompanying documentation, so you had to look elsewhere for those capabilities.
At the same time I took a look at Visual Basic 1.0, I had a large project in the works for a client. I had to design and build a shop floor solution in 120 days. There was no data model, database, application design, or any other foundation to start from. The client wanted me to use Digital's VAX hardware running the VMS operating system, and use RDB as the database. At about that time, one of my contacts at Digital provided me with a library (DLL) that talked to RDB. My team did some prototyping and testing and everything performed reasonably well. They actually built and rolled out that application in about 120 days. There was lots of trial and error in the process, but it paid off.
Figure 1 shows the overall design of the system. The application ran on the client workstations and talked to RDB through the Digital library. By the way, as far as I know that library never went into production. So, the production system was built on sort of a one-off library. But it worked.
.gif)
Figure 1My System Design using Visual Basic 1.0
Visual Basic was a tremendous asset in that project. The final application had an easy-to-use UI, a high-performance database, and ran smooth as silk.
Versions 2.0 and 3.0
After this application was running for several months, Visual Basic 2.0 was released. It was snazzier, but still had no database features. I upgraded the client's application to Visual Basic 2.0 to take advantage of some of the new features, and put the new version into production. Visual Basic 2.0 did not radically change my development process, but it did smooth out the bumps and performed better than version 1.0.
As time went on, I began to hear about the next Visual Basic upgrade, which was supposed to have some radical features. At Tech•Ed, I got my hands on an early copy of Visual Basic 3.0, and boy was I amazed. Now Visual Basic was much richer—it switched from VBXs to the more flexible OLE control (OCX)—and had native support for communicating with databases using ODBC. What a change that brought to the development process.
I used Visual Basic 3.0 to build all kinds of applications. Of course, there were the client/server applications that took the world by storm. The easy-to-use database features in Visual Basic 3.0 plus the ODBC drivers from Microsoft and others opened the world of programming to a large number of developers.
There are several things to remember from the days of Visual Basic 3.0. First, there were some complaints about application performance. I was always able to build correctly performing applications using any version of Visual Basic. Notice that I said "correctly" instead of high-performance. One of my application design criteria is always the level of performance required for the application. If a client requested that the user interface display data in 1.5 seconds in a particular part of the application, then I designed with that in mind. By using the proper drivers, limiting the controls on a form, using control arrays, watching how the application handled repetitious functions (such as loops), carefully constructing the data access features, and so on, I built applications that performed as specified. Of course, Visual Basic 3.0 compiled to P-code, not to native code. But that was manageable because most of an app's code does not benefit tremendously from native compiling anyway.
At about this time I also began to build applications for a variety of nonstandard purposes. Many of my clients were using Windows® for Workgroups clients and VMS servers. Back then, Digital distributed the Pathworks LAN package for integration of PC type workstations and VMS servers. Pathworks was a LAN Manager networking package and thus was somewhat similar to networking with Windows NT®.
One of the problems my clients had was controlling the configuration of client workstations. Users could and would frequently change .ini settings. Users also had problems with network shares and other configuration issues. To solve these problems, I used Visual Basic 3.0 to create a login program for Pathworks. This login program used a separate configuration file for each user to control drive mappings and other settings. One of my clients had problems with a few users who insisted on tweaking the data settings and other configuration settings in various .ini files. Changing these settings was driving the support people crazy and causing problems with dates that went into a client/server database. My project manager asked me to fix the problem. So I opened Visual Basic, created a bit of code, and a couple of hours later, the problem was solved. If a workstation logged in on the network, it had the right configuration—period. The login problem checked the .ini files against a master file on the server and changed what needed to be changed—it even rebooted the workstation if necessary.
A short time later, another client had to migrate files and mail messages from a VMS all-in-one application. The client was faced with a six-figure price tag on custom software and services to perform this task. I thought about this problem for a while. One savvy developer used Visual Basic 3.0 and a custom control to write a custom application in two weeks. That one application probably saved this client more than $100,000.
Version 4.0
As time went on, developers longed for more capabilities in Visual Basic. For instance, one of the things that I wanted to do was create an application that used RPC to communicate with applications on other systems. I was all set to write an RPC wrapper in C that could be called by Visual Basic-based applications. Then I went to Tech•Ed again.
This time I had the good fortune to meet a Visual Basic product manager and learn about a new version of Visual Basic that was getting close to beta—Visual Basic 4.0. I was astounded at what I heard. With this new version, you could create classes, which turned into OLE servers (now called COM components) when compiled. The new version also contained both 16- and 32-bit versions. This was probably the biggest driving force behind migrating the world to the 32-bit features of Windows 95. I remember how anxious I was to get my hands on this beta, and I was not disappointed.
Visual Basic 4.0 brought the world of object development to Visual Basic-based developers. Now you could create your own classes (objects) and package them into components. I quickly learned that components could save a tremendous amount of time in the development process. At the time, client/server programming was still going strong. One of the features that most client/server programs had was a splash screen. Many of you have created splash screens over and over again. I figured I might be able to build a splash screen as a component that I could reuse in other projects. I was right, and it only took a few hours to work out. That was the last splash screen I ever built.
Visual Basic 4.0 also introduced Remote Data Objects (RDO), a high-performance database library for building client/server database applications. RDO made it easier to build applications that met performance goals, especially when large numbers of users were involved.
The component and database features of Visual Basic 4.0 dramatically expanded the ability to build applications. A feature known as Remote Automation allowed you to access OLE servers over the network. This was in the days of Windows NT 3.x, before Windows NT 4.0 introduced developers to DCOM. Today, DCOM is considered slow. However, properly applied, both Remote Automation and DCOM can be used to accomplish things that can't be done easily any other way. Remote Automation provided a standard feature that went beyond what could have been done with a simple RPC wrapper.
Development with Visual Basic 4.0 really took off. With the right prototyping and testing, applications were created that performed well. Creating and using classes in applications allowed many organizations to take advantage of object-oriented development without having to invest heavily in C++.
If you were developing applications in Visual Basic 4.0 that were built on classes, you were ahead of the game. It was easy to use those classes and even upgrade them to later versions of Visual Basic. When I started teaching how to build Web applications, many people would ask the same question: how long will it take to migrate my applications to the Internet? I always responded the same way: if your application is n-tier and built on classes, you can have part of it on the Web quickly. If not, you are going to have a harder time. Visual Basic 4.0 thus brought object development to the masses and enabled developers to quickly build almost any type of application.
Versions 5.0 and 6.0
Visual Basic 5.0 brought big advances in a couple of areas. First, you could finally compile applications to native code. This was the long-awaited version of Visual Basic that could generate applications that were within a hair as fast as many C++ applications. For instance, I have a sample application written in C++ and Visual Basic 5.0. Either one would report faster times if you moved the mouse while the other was running. They were that close in speed. You could also compile applications to P-code just like in previous versions of Visual Basic. Thus, you could make the decision to trade speed (native) for smaller code size (P-code).
Visual Basic 5.0 could also create ActiveX® controls. This version was released about the time the Web was gaining critical mass, and at the time the ability to create ActiveX controls in Visual Basic was a big deal. Come to think of it, it's still a big deal today. Today, intranets, client/server applications, and standalone applications depend on ActiveX controls for so many critical functions. ActiveX controls provide a richer user experience that can be provided in a browser alone.
Of course Visual Basic 5.0 enhanced the ability to build classes, client/server applications, and other types of applications that you built with previous versions of Visual Basic. If your applications were processor-intensive, then the native compilation features could really make them sing.
In the late 1990s the Web revolution was in full swing and Visual Basic 6.0 was there to meet it. A new feature, Web Classes, brought Visual Basic full force into the Web world. Even ActiveX controls gained functionality that made them even more suitable for use on the Web. It is really amazing that you can use ActiveX controls to easily download and manipulate things from the Internet. You can also build ActiveX documents—components with an interface that run inside of a container, such as the Office Binder or a browser such as Microsoft Internet Explorer.
Visual Basic 6.0 also brought developers into the world of ADO. ADO was pioneered in ASP, and having ADO support in Visual Basic brought the two worlds together. Finally, you could easily build components for use in Windows or Web applications. Now that was true reusability. In Visual Basic 6.0, you could also pass ADO recordsets across processes. This allowed you to call a method that returned a recordset.
Visual Basic 6.0 introduced many other new features. For instance, FileSystem objects let you easily work with system objects such as folders and files. Not only did FileSystem objects allow easy, standardized access to the file system, they are the same objects that are used by ASP. No more Open #1 statements!
The standardization of ADO and the FileSystem objects let you migrate code between Visual Basic and VBScript quite easily. I have converted many applications between the two. In fact, it is always fun in an ASP class to show students how to migrate the ASP and ADO code to a Visual Basic class, then call the Visual Basic classes method from ASP.
Along the same lines, Visual Basic 6.0, ADO, and ASP reset the performance standards for Web applications. The FMStocks application that was built for Tech•Ed 1999 really set the bar for performance. Everyone involved in either building or testing FMStocks was amazed at the results. This application demonstrated that building high-performance apps was no longer tremendously costly, as long as you played by the rules. FMStocks also provided a great standard data layer that could be used in your applications.
Visual Basic .NET
Visual Basic .NET provides so many features, it is by far the most comprehensive upgrade yet. Since Visual Basic .NET sits atop the .NET Framework, Visual Basic is no second-class citizen to application development in the .NET world. There is practically nothing that you can do in C# that you can't do in Visual Basic .NET, and vice versa.Visual Basic .NET will make it easier to build many types of applications. Whether you are building a Web, client/server, or standalone application, you can do it quickly with Visual Basic .NET. The results should be outstanding as Visual Basic .NET is demonstrating tremendous performance gains as well.
In fact, those classes that you wrote beginning with Visual Basic 4.0 can migrate directly to Visual Basic .NET. You can call Visual Basic 6.0 classes from a Visual Basic .NET application and vice versa. You can also use ActiveX controls.
Visual Basic .NET really changes things for the ASP developer. Gone are the days when all you could use was a scripting language in your Web applications. Instead, you have full-fledged Visual Basic .NET. Web applications will likely show tremendous performance improvements over existing ASP applications.
The new event-driven nature of ASP.NET will also look very familiar to the Visual Basic-based developer. Once developers get used to building Web Forms and server controls, the Internet will be transformed. Sounds like the old Visual Basic 1.0 days, right?
Those same classes you created with Visual Basic 6.0 can, with a bit of work, be turned into Web Services. Now you can publish methods in those classes for use by others in your organization or publish them in UDDI on the Internet.
Conclusion
Visual Basic .NET is both an evolutionary and a revolutionary upgrade. If you have been building applications with Visual Basic for years, you have a great set of skills that are all transferable to Visual Basic .NET. The language skills in particular will take you into the Visual Basic .NET world. ADO.NET and various other .NET features will seem familiar to you once you get used to the new objects and their methods.
Upgrading existing applications to Visual Basic .NET will take some work. But you went through this in upgrades between Visual Basic 3.0 and 4.0, and to some extent other versions. I personally look at Visual Basic .NET as a great upgrade and a chance to use those skills that my team has learned over the years. I can also do things for my clients now that I either could not do before or that were just too costly. Happy birthday, Visual Basic!
|
.gif)
.gif){kind=small}