by Peter G. Aitken (c)1998
Originally published in Visual Developer magazine
No, I am not referring to high-spirited hand slapping by six-fingered aliens (although that might make a more interesting column!). Rather, its the new release of Visual Basic, variously referred to as Version 6 and Visual Basic 98. I have been working with the pre-release versions of VB6 for several months now, mainly to revise my book Visual Basic Programming Explorer (which has been renamed as The Visual Basic 6 Programming Blue Book; click here for more information) but also with the intention of bringing my readers a preview of what's new. Now that the cloak of secrecy has been lifted by Microsoft, I am free to give you the poop.
I'll start right off by saying that this is not as significant an upgrade as was version 5. After all, version 5 brought us a totally new development environment interface and true compilation along with a host of other important although less earthshaking goodies. Even so, version 6 provides enough added oomph so that most if not all Visual Basic developers will be dusting off their credit cards. As before, the update is available in Learning, Professional, and Enterprise editions.
Perhaps the most significant changes are in the area of data access. This is appropriate, as database programming is what Visual Basic seems to be used for the most. There is an entirely new data access technology called ActiveX Data Objects, or ADO version 2. As the version number suggests ADO is not actually entirely new, having existed in a previous version but having been part of Visual Basic. In any case it is included as part of Visual Basic 6, and represents a significant improvement over the older ODBC, DAO, and RDO technologies. These earlier data access technologies are still supported, of course, and usually it would not be advisable to convert an existing database application from DAO to ADO. For new projects, however, ADO is definitely the way to go.
ADO makes use of OLE DB, a general purpose set of interfaces that is based on the Component Object Model (COM). At the basis of the OLE DB philosophy was the desire to provide a single set of interfaces that could access data regardless of where the data was located. OLE DB is designed to access not only traditional information sources such as Oracle and Jet database files, but in non-traditional locations such as MSMail and Excel. In the past, data located in such non-traditional locations had to be extracted and then imported into a standard database file format before it could be viewed and manipulated across the enterprise. With OLE DB, data remains in its original native location. AT the data end, OLE DB provides whatever tools are needed to access the data "where it lives." At the program end, OLE DB exposes a consistent set of interfaces that remain essentially the same regardless of the nature or format of the data being accessed. ADO provides a set of wrappers for OLE DB, providing Visual Basic programmers with access to the OLE DB interfaces through an object model similar to those used previously.
ADO represents an evolutionary change over RDO and DAO, just like those technologies represented an evolutionary change from ODBC. Of course it is not completely accurate to view these various data access technologies and completely independent entities. Even so, ADO is different enough so that the switch from thinking in DAO/RDO terms to thinking in ADO-ese is not a trivial one. Given that ADO is significantly easier to use, however, the switch will be welcomed by most. Here's an indication of what the change means. I recently revised my book Visual Basic Programming Explorer for the new Visual Basic release
When you examine the ADO object model, the first thing that will strike you is the small number of objects it contains. That's right, there are only seven objects in the ADO model, and some of those are optional! Then, as you look deeper, you'll see that the ADO model is a lot less hierarchical that earlier data access object models. In other words, the various object - or classes, if you prefer - are less dependent on each other. In some cases, the dependency exists but is hidden from the programmer. As a result the programmer's job is easier.
The four main ADO objects are as follows:
- Connection object. Represents the link between the data source in use and the ADO interface. This object maintains information such as the cursor type, connection and query time-out values, username and password, and the name of the provider.
- Command object. Represents a query or statement that is sent to the data source for processing.
- Recordset object. Represents a set of data records that is returned by the data source in response to a query.
- Field object. Represents a single column of data, or field, within a recordset. Each Recordset object has a Fields collection that contains one Field object for each column in the recordset.
The fundamental sequence of events is using the ADO interface, then, is as follows:
1. Create a Connection object and use its Open method to create the link to the data source.
2. Construct a Command object to create the query that you want to run.
3. View and manipulate the Recordset object that is created as a result of the query, using its Fields collection to access individual columns of data.
4. Close the connection.
The design of the ADO interface provides significant flexibility. This means that there is always (or so it seems) more than one way of doing something. For example, a recordset can be created and populated without explicitly creating a Connection object. While I suspect that a Connection object is created implicitly, behind the scenes so to speak, this still simplifies the programmer's task. If you do explicitly create a Connection object you have the ability to associate multiple recordsets with it. Likewise it is not always necessary to create a Command object, as certain relatively simple commands can be constructed as strings and passed directly to a Recordset object for execution.
The remaining three ADO objects are:
- Error object. Represents information about a data source error. The Connection object has an Errors collection containing one Error object for each error reported by the data source.
- Parameter object. Represents a single piece of information, or parameter, that is part of a command. The Command object has a Parameters collection containing one Parameter object for each parameter required by the specific command.
- Property object. Represents a property of an object. Connection, Recordset, Field, and Command objects each have a Properties collection containing a Property object for each of their properties.
Along with the ADO data access model comes a new assortment of controls that utilize the ADO interface. These new controls are, for the most part, new versions of existing controls that use ADO instead of the older DAO and RDO technology. At the center is the ADO Data control, which functions pretty much like the older Data control, creating a connection to a data source and providing a visual interface that the user can click to navigate from record to record. There is also a new assortment of data-aware controls that can be bound to an ADO Data control - the DataDrid, DataList, and DataCombo controls provide the same functionality as the older dbGrid, dbList, and dbCombo controls. Data-aware controls gain additional flexibility with greatly improved support for dynamic binding. In the past, a data-aware control could be bound to its data source (such as a Data control) only during program design. With VB6, binding can be done dynamically in code. This becomes a very powerful and flexible tool when combined with the ability to dynamically add controls to a form at run-time with the Add method.
Another particularly significant change is support for asynchronous operations. Requests, such as a query, can be submitted with the instruction that it be processed in the background. Your program is notified when the process is complete by means of an event. There is no need for your program to sit around twiddling its digital thumbs while a query executes. Thus, during a lengthy asynchronous operation the FetchProgress event is fired periodically and can be used to update the program on the progress of the operation. When the operation has been completed the FetchComplete event is fired.
Some other new controls add to the database programmers happiness. The DataRepeater control serves as a container for a user control that you create to display one record from a database table. When in the DataRepeater, the user control automatically displays multiple copies of the user control, each displaying a different record. The user can scroll through the table using the HOME, END, PAGEUP, PAGEDOWN, and arrow keys.
The FlegGrid control has been enhanced. In addition to its usual function of displaying a recordset, it can also display a hierarchy of ADO recordsets, with each individual recordset displayed in a separate band within the control. Each band can be formatted independently, also.
I could go on and on, but the new Visual Basic has been improved in areas other than data access and I'd like to devote a little time to them. I'll close this section with a brief description of some of the other enhancements that will warm the hearts of database programmers. Remember, some of these features are available only in the Enterprise or Professional editions of Visual Basic.
- SQL editor lets you add new stored procedures to existing SQL Server and Oracle databases.
- Passable recordsets. ADO recordsets can be passed between processes or machines.
- Data sources. You can program your own controls and classes thats serve as data sources to which other controls can be bound.
- Data report provides drag-and-drop data report design.
- Data Environment is an interactive design-time tool for creating ADO objects.
The enhancements in Internet programming may not be quite as awesome as the database programming improvements, but they will be equally welcome. First off, at least the first thing I noticed, is that the Internet Transfer control finally works. While this control has been around for a while, early versions were real dogs - it was difficult if not impossible to get it to do anything properly. Even when "updated" in the Visual Basic service packs this control continued to cause a lot of headaches. This was a shame, too, because the Internet Transfer Control promised a quick and easy way for a Visual Basic program to perform FTP and HTTP transfers. The version that ships with Visual Basic 6 seems to be fine, and I quickly used it to write a link verification program (for details see my web site at http://www.pgacon.com/visualbasic.htm). With this control and Visual Basic's text handling power there are lots of possibilities - web crawlers, automated search engines, and the like.
Of course, finally getting a control to work properly cannot really be considered an impressive upgrade! In the Internet arena there are two major additions to Visual Basic. First is the ability to write IIS (Internet Information Server) applications. An IIS application uses a combination of HTML and Visual Basic code. It runs on a Web server where it receives and processes requests from browsers. The tasks performed by an IIS application can range from the extremely simple, like returning the requested HTML page, to the complex and sophisticated, such as querying a database and generating an HTML page "on the fly" to be returned to the browser. IIS applications run on Microsoft's Web server, also called Internet Information Server.
An IIS application can be used to accomplish the same things that are done with CGI and embedded scripts, and offers additional power as well. To the end user, the IIS application appears only as the HTML pages that are returned and displayed in the browser.
The second major Internet enhancement is the ability to program dynamic HTML, or DHTML, pages. In DHTML, each element on a Web page - text, images, buttons, and so on - is no longer a static chunk of data that can be displayed but nothing more. With DHTML each of these items exposes properties, methods, and events - it is dynamic. You can write Visual Basic code that responds to events on a DHTML page, changing the page format or contents in response to user actions. This processing occurs on the remote computer, without processing having to be returned to the server.
If you are confused, I don't blame you. It seems that IIS applications and DHTML applications are intended to perform essentially the same task. And what about Active Server Pages, or ASP, another technology for presenting dynamic Web sites to the user? Let's take a look at the differences.
DHTML applications are dependent on the user having the Microsoft Internet Explorer browser version 4.0 or later. Clearly, the only situation where you can be sure your users will all have this browser is on an Intranet. DHTML applications are obviously not suit for wider Internet use. DHTML applications perform most of their processing locally, on the computer where the browser is located.
IIS applications do not require the user to have any particular browser or operating system, and are therefore suited for Internet use. Most of the processing with an IIS application is performed on the server. While IIS applications can be used for simple page authoring tasks, the primary intent of this technology is the development of complex web-based applications.
ASP applications also perform most of their processing on the server, using either VBScript or JScript code located in an .ASP file. An ASP script can use ActiveX components to access a database o perform other processing tasks. There is considerable overlap between the capabilities of ASP and IIS applications, with ASP falling on the "web page authoring" and of the spectrum and IIS falling on the "complex application development" end.
Given all of Visual Basic's new capabilities in the area of creating Web applications, it is only appropriate that it helps you to deploy them as well. The new Package and Deployment Wizard makes it relatively painless to package you application and to distribute it, either locally or to a Web site. This Wizard replaces the old Setup Wizard and is used for all types of Visual Basic projects, not just Web-related ones.
New and Improved Controls
Controls are still at the heart of Visual Basic, and the new release provides a decent assortment of new and enhanced controls. I have already mentioned some of the database-related controls above. Other new and enhanced goodies include:
- The DateTimePicker provides a drop-down calendar that can be used to select a date. By changing properties it can also be used to select times. Related is the MonthView control which permits selection of a range of dates.
- The Coolbar control provides user-customizable toolbars like those used in Internet Explorer 4.0.
- The ImageCombo control is like a regular ComboBox but can display images as well as text.
- The ImageList control has been improved to support .GIF, .JPG, and .CUR image files.
- The MSChart control now supports data binding (to the new ADO Data control only).
Language and Object-Oriented Features
Basic just continues getting better and better. Functions can now return arrays, which enhances not only the power of standard Basic functions but also means that classes can have properties that are arrays. You can also assign the contents of one array to another with a single assignment statement, as long as the "receiving" array is dynamic.
In a similar vein, user-defined types can be the arguments or return types of public properties and methods. This adds one more layer of flexibility to creating your own classes.
Another new feature that I think will prove to be very useful is the CallByName function. By using this function you can call an object method or access an object property by having the object name and the property or method name in a string variable and not hard-coded into the program. The syntax goes like this:
CallByName(object, procedurename, calltype,[arguments()])
The arguments object and procedurename are type Variants containing the name of the object and the name of the method to be called or property to be accessed. The third argument is a constant specifying whether the call is to a method, to set a property, or to get a property. The final argument(s) are any arguments required by the method or property procedure being called.
Another major change is that Visual Basic's file system is finally being modernized with an object interface. The File System Objects, or FSO, provide a hierarchy of classes that provide both file access (reading and writing data) and file management (deleting files, creating folders, etc.). Here, for example, is code that will populate a dynamic array with the names of all the DLL files in the application's active folder:
Dim fs, f, f1, filelist()
Dim i As Integer, j As Integer
i = 0
Set fs = CreateObject("Scripting.FileSystemObject")
Set f = fs.GetFolder(App.Path)
For Each f1 In f.Files
If LCase(Right(f1.Name, 3)) = "dll" Then
i = i + 1
ReDim Preserve filelist(i)
Set filelist(i) = f1
Similar techniques are used for FSO writing and reading of file data. Note that as of this writing the file access part of FSO is incomplete, working with text files only and not with binary files, which still must be accessed using Visual Basic's traditional file statements. The file management side of FSO, however, seems fairly complete.
There are plenty more new and improved capabilities in Visual Basic 6, but I have covered the more important ones. Of course, lots of things have not changed. The user interface is the same, the compiler and compiler options seem to be unchanged, the Visual Data Manager remains the same, and so on. Overall it is an impressive but not an earthshaking upgrade
Have you ever wondered just what was lurking inside your Visual Basic projects? This is mostly a concern with large, complex projects, and particularly so when more than one programmer is involved. Sure, Visual Basic will tell you if you use a variable or constant without declaring it, but what about the reverse - declaring a variable, object, or constant and then never using it? The same possibility exists for typedefs, API declarations, and procedures. It is even possible to have controls on your forms that are never referenced, and entire forms in a project that are never displayed. There is plenty of opportunity for unneeded code to be left lying around in a project, causing slower execution, bloated distribution files, hard-to-read source code, and other problems. Locating and removing redundant and unused code is a difficult and time-consuming job, with the added problem that you'll never know the benefits this fat-trimming will bring to your project unless you actually do it.
But wait - here comes (sound of the William Tell Overture) VBCompress Pro version 6 to save the day. Billed as an analysis and optimization tool, VBCompress goes through all of the files in a project with a fine-toothed comb and spits out a detailed report that includes information on unnecessary code as well as metrics on the project, such as by-file data on error handling, default data types, and option settings. VBCompress can also create an optimized version of the project that has all unnecessary code either deleted or commented out. The program does its job quickly, and the available options for report format and contents are truly awesome - perhaps too much so, as the overabundance of report options can make it difficult to obtain just the information you need. With a little patience, however, you will get the hang of customizing the program's output to suit you. At $195 this program may be a bit steep for casual programmers, but for professional developers the investment should be well worth it. I wonder if a "lite" version might attract some customers who would otherwise pass it by? In any case, you can find our more about VBCompress Pro and download a demo version at WhippleWare's web site: http://www.whippleware.com/vbcp.htm. The program supports version of Visual Basic up to release 5; an upgrade for Visual Basic 6 is in the works.