Image of Navigational Map linked to Home / Contents / Search VB6 - A first look

by Jim Karabatsos - GUI Computing
Image of Line Break

I admit to being underwhelmed by the latest release of Visual Basic, but that is probably related to the fact that I take a lot more for granted than I used to. VB6 is a very good development tool and VB6 has some neat new features. I guess that I have been spoilt by the Service Pack deployment model. I somehow expect that a major version number upgrade has to offer so much more. In many ways, VB6 is VB5 Service Pack 4. That's a little unfair and very much does not do justice to the amount of work that has obviously gone into the release, but I bet that I will not be the only one to feel that way.

Microsoft does not exist to create software - it exists to create wealth for its shareholders and I understand that at some point all of the various improvements need to be rolled into a major release and charged for. I certainly do not want to go back to the bad old days where we would have to wait for a full version upgrade to get bugs fixed and for access to new technology.

The bottom line is that there is no rush to go to VB6. We have several VB5 projects on the hop at the moment and we do not feel any pressure to convert them to VB6. However, new Win32 projects we start or major updates will probably be done with VB6 as there are certainly some features there that are very nice, especially those related to data access.

The big news with data access in VB6 is the total integration of ADO as the data access method of choice. Microsoft has given us all fair warning that ADO was the way forward and I, for one, am quite happy about that. ADO (and the underlying OLE DB layer) make a lot more sense than DAO for all sorts of reasons. While applauding ODBC, I have been on record for a long time as questioning the validity of the assumption that all data is accessed relationally. OLE DB understands that some data is not meaningfully accessed and manipulated relationally and does not impose a requirement that a data provider implement an SQL interface. This means that we should see all sorts of data stores expose an OLE DB interface - file and directory systems, e-mail systems, logging systems - you name it and it can be exposed for access via OLE DB. I am not going to go into all the new facilities of ADO 2 here but I would advise you to take a good look at this technology.

One of the really cool new facilities in ADO 2 is the ability to pass Recordsets across process and machine boundaries using COM, DCOM or HTTP. This is a good fit for n-tier application architectures (and means that I can send my RemoteRecordset classes to a much-deserved retirement).

ADO 2 was released formally just prior to VB6 and can of course be used from VB5. VB6 does, however, provide an ADO data control that behaves much like the DAO data control and to which all the common bound controls can bind. (DAO is, of course, still supported both in the language and through the data-binding interface).

The Pro and Enterprise editions of VB6 also include the Data Environment Designer which is a way of setting up one or more ADO connections each of which can have one or more commands. Several system-level events are defined and can be handled at the environment or command level so you can centralise some event handling. All these objects can be manipulated in your code at run time as well as in the Properties window at design time. The really cool thing is that you can bind controls on different forms to these objects so you can easily keep the visual representation of data synchronised across several forms. It's nowhere near as capable as Delphi's data modules but it is a step in that general direction.

Speaking of binding, you can also create your own classes and controls that act as data sources and consumers and bind them through the BindingsCollection object. This is something that I want to play with more before I try to explain it in detail, but it sure looks cool.

Because a data source can now have more than one bindable object, bound controls now have another property called DataMember in addition to the DataSource and DataField properties. The DataMember property would specify the individual command object within a data environment that is being bound to. Also new is a DataFormat property that allows you to specify the way that data is formatted when read from and written to the data source. This is actually quite neat because it refers to an object (StdDataFormat) that has events you can hook into to do all sorts of custom formatting if you need to.

Several of the data bound controls have been enhanced to support some of the new features of ADO. For example, FlexGrid has now been enhanced so that it can display a hierarchy of ADO recordsets, with each recordset being a separate band within the grid. All new is the DataRepeater control which allows you to place a UserControl in it. That user control is repeated as many times as will fit by the DataRepeater control, with each one "bound" to a different row in a recordset. You would then place individual bound controls like textboxes, checkboxes and so on inside the user control. This gives us VB programmers a facility pretty similar to sub-forms in Access or MROs in Delphi.

The Data Report facility is similar in concept to Data Dynamics ActiveReports. Don't bother with this one, folks. Get ActiveReports. Trust me.

The Enterprise edition of VB includes very nice tools for managing database objects from within VB itself. In VB6, Microsoft has made support for Oracle a priority, so much so that the tools recognise whether you are talking to an Oracle or SQL Server database and generate (or just check) SQL statements that conform to the idiosyncrasies of each. You can also view the data and metadata in your database directly from the VB environment.

The OIR (Obligatory Internet Reference)

Prior to VB6, writing IIS applications required that you develop some ASP scripts that called upon the services of ActiveX components that you developed using VB. If you are like me, this constant swapping between VBScript and VB was a challenge (have I mentioned that I hate VBScript?). The new WebClass designer does away with all that. It generates a simple ASP script that essentially just packages up the requests received from the browser and sends them to your application (which has been compiled to an ActiveX DLL). The ASP code is minimal and there is no need to look at it at all (which suits me just fine!). You simply write event handlers as required to implement your application.

With a WebClass application, all the processing is done on the server and (provided you use standard HTML for the interface) your application can be accessed by any browser. If you are using IIS and need to cope with browsers other than IE 4, then this is a good alternative to investigate. If you are developing for an intranet or otherwise know that all your users will be using IE 4, then look into DHTML applications to transfer some of the processing to the client.

The facility to create components has been beefed up in VB6. In addition to the already-mentioned ability to create data sources and consumers, VB6 lets you create lightweight user controls (ie ones that do not have a hWnd).

You can specify whether a control creates and maintains its own permanent hDC or shares one as needed using the new HasDC property.

When you run (F5) a component project, VB6 gives you the ability to choose where to run the component for debugging. This lets you site the control inside a browser, for example, and debug it there, which is a neat and very useful trick.

As procedures can now return arrays, classes can now have array properties so you don't need to fudge it like you had to in VB4 and 5. You can also assign one array to another in a single statement (as long as the target array is dynamic).

Public methods can now also take UDTs as parameters and return UDTs as the return type, including arrays of UDTs. In VB5, you had to create data-only classes and use them in place of UDTs, which incurred quite some overhead because each object instance has about 100 bytes of overhead. We had worked around this by packing data into string arrays and unpacking them on the other end. This is much neater (and about time, too!).

VB6 allows access to a property or method using the CallByName function. This takes a string that contains the name of the property or method to be accessed. This one is going to cause all sorts of maintenance nightmares and I would ban junior programmers from using it without approval from a senior developer (in fact, I just did <g>) but it can be very useful in some limited circumstances.

VB6 provides access to a scripting object called a Dictionary. If you have done a lot of ASP work, you know all about it. If not, it is an associative array - data of any type is stored in the array and is referenced by a unique key. Keys are usually integral items (integer, long, currency) or strings but can in fact be anything except an array. They are similar to a Collection but less prone to errors.

A much-appreciated new capability is that CreateObject finally lets you specify a remote machine on which to create an object. That's one more of my utility routines can be retired. Also, the new MTSTransactionMode property lets you specify the transactional behaviour of a class used under MTS. I guess that this is fledgling support for a COM+.

The Package and Deployment Wizard is basically a total re-write of the Setup Wizard. It can deploy a CAB file to a Web server, network share or any other folder. It supports all the data access engines used by VB (ADO, OLE DB, RDO, ODBC and ADO). It can deploy WebClass and DHTML applications and gives you better control of the Start Menu groups and icons created by the setup program. Wise it isn't, but it is an improvement.

Most wizards have been given the once-over and have improved. I'm not a big fan of wizards in the development environment (even though I write lots of them for our users) so I have not looked at them very closely. Take a look and see what's new.

Well, that about wraps up our whirlwind tour of VB6. We will of course be covering more aspects of VB6 as well as delving more deeply into the ones presented above over the coming months as we use them in real projects. We will never deploy any pre-release software, nor will we use it in the development of real projects even if they are not due to ship until after the release date. We all know how fluid release dates can be. All of the above has of necessity been based on tinkering and scouring through the documentation rather than real-world use of these technologies.

What's missing?

VB6 is a nice environment to work in. It works well and is a worthwhile (if not urgent) upgrade. What is not there is probably not going to be missed by most developers.

I am still a fan of inheritance. Yes, I do understand that inheritance can make your application brittle if used incorrectly. I don't accept that it is a foregone conclusion that VB developers will use it incorrectly. A large part of what I do is to develop standards and re-useable components and resources. My job would be much easier with inheritance and the outputs of what I do would be easier to use and more, not less, robust. You won't miss it if you are doing straight RAD business development, but if you do miss it, you'll miss it badly. <sigh>. If it weren't for ActiveReports, I would be championing a crusade within GUI to convert to Delphi or VJ6, where at least the developers are not treated as incapable of using inheritance and other "advanced" language facilities properly.

I want to be able to leverage the fact that VB programs are now compiled to native op-codes. Why can't we use LIB and OBJ files? Indeed, why can't we create them? Why can't we create DLLs that export static functions? Why can't we call through a function pointer to external routines and into VB modules through an AddessOf pointer? Why can't we have fair-dinkum pointers to do with as we wish?

Why can't we turn off the ETC (Evil Type Coercion) introduced in VB4? I really want an Option Strict-And-I-Really-Mean-It (a.k.a. Option Anal). I can't even begin to estimate how much time I have wasted tracking down and squashing bugs in my own (and other's) code masked by ETC.

Sorry, I just had to get that off my chest. My doctor said that these episodes will pass if I keep up the therapy.

Written by: Jim Karabatsos
August '98

Image of Arrow linked to Next Article
Image of Line Break