The answer is that VB6, and most versions of Basic, were created by a process of accretion. Good ideas were added to the language, and if they proved to be useful they stuck, if not they withered. The resulting language was often a logical mess, but its one outstanding feature is that it was easy to use, at least initially.
This is the reason why a language like VB6 excites so much passion. The programmers who use it know that it’s a great language for getting off the starting blocks, and if its approach causes a few problems further on down the track, then so be it. After all, that far into a project we know the technology well enough to fix it. However, programmers standing on the sidelines looking at the language had a rather more disapproving view of its messy syntax and patchy facilities. From their point of view, everything seemed to have been bolted on just to get round some deficit or to patch up an earlier poor decision.
Many VB6 programmers were very aware that the language had problems, and the request made most often for the next version of VB was to make it “fully object-oriented”. It was never clear beforehand what “fully object-oriented” actually implied, but when VB.NET was released it became clear. The new, logical, object-oriented VB.NET could not possibly be 100% backward compatible with VB6. If it were, it would be neither logical nor object-oriented. This implies that VB6 programs cannot work under VB.NET without modification.
Unfortunately, the first version of VB.NET lacked many of the features that made programming easy under VB6. It was a clean, logical, powerful language, but many programmers thought that it ignored the requirement for ease of programming in favour of a rigid adherence to principles. The latest version of VB, Visual Basic 2005, has added many of the features that were missing from the first .NET version, and in many ways it is more deserving of the name VB8.
After conversion you may find some lines commented out awaiting your attention
It may well be that VB 2005 is beginning to look more like a true descendent of VB6, rather than C# with a modified syntax, but this doesn’t make it backward compatible. You still have to put some work into converting VB6 programs, and the question is – is this work worth it? It depends on how you go about it. There is an upgrade wizard that will examine your code and report back what can and cannot be converted automatically to .NET. In practice this can vary from 20% to 80% of automatic conversion, depending on the features that the VB6 application makes use of and how well it was written in the first place. It is certainly true that mapping messy code onto clean object-oriented VB 2005 is more difficult than migrating well-constructed code.
It is sometimes suggested that the best way to deal with the problem code is to recode it in VB6 and try the automatic conversion again. My personal view is that this is not the best or most efficient thing to do. Instead, learn VB 2005 and the .NET Framework, and do all your new work on this side of the fence. It has the advantage of allowing you direct optimisation of expression in the target language. You will also “know” the translated code so much better.
The great majority of the code that cannot be automatically converted is relatively trivial to do manually. In fact, after you have spent some time converting a large program you can’t help but wonder why more of the task, graphics in particular, couldn’t have been automated. Of course when you examine what you are doing more carefully you usually discover that you are making choices about how to convert the VB6 instructions. It is a shame that problems with upgrading graphics aren’t directly addressed in VB 2005, since having to master the GDI+ as a way of creating simple shapes, while not difficult, can be needlessly off-putting to the beginner. There are no equivalents of the VB6 shape controls, but there seems to be little reason why not.
Consulting the conversion report is vital in understanding any difficulties
There are some important improvements to upgrading in VB 2005. You can now upgrade applications that use MTS and COM+ components. There are also some new .NET classes that allow VB6 controls to be upgraded mostly without change. The WebBrowser control is particularly welcome, as this was a feature of VB6 that encouraged designers to host web content within their application, and its absence in VB.NET made it difficult to convert such applications. Of more general interest is the availability of components roughly equivalent to the ToolBar, ImageList, TreeView, ListView, RichTextBox, ProgressBar, StatusBar, CommonDialog and MaskedTextBox. Why weren’t these well-used components in the previous version? I suppose the answer has to be that there is only so much you can do at a time.
As well as these additional components, the most significant simplification in upgrading has been brought about by the My objects. These are a collection of ready-to-use objects which implement many of the VB6 built-in objects that were missing until now. For example, the App object can now be upgraded to the My.Application object, the Clipboard object to the My.Computer.Clipboard object and the LoadResString., LoadResData, LoadResPicture functions map directly to the corresponding methods of the My.Resources object.
The introduction of objects, i.e. classes that are automatically instanced when you reference their name, is a big change in VB 2005. As well as the My objects, the VB6 way of treating forms as objects has returned. One of the confusing things in VB6 was that a form that you had created, e.g. Form1, was both an object you could use and a class that you could use to create additional instances of the type. You can now do this in VB 2005 if you want to, and let the compiler create an instance of the Form1 class behind the scenes. Of course if you are a purist you will want to modify this code so that Form1 is a class that instantiates to an object before you use it.
Existing VB6 forms are also upgraded to use the new partial type implementation. This splits the form definition into two files – one for the Designer to use for its automatically generated code, and one for the programmer to customise. This again simplifies upgrading, because there are no generated lines of code in the part of the form definition you are working with.
There are a great many smaller or more technical upgrading features which all go towards helping smooth the upgrade path. However, the bottom line is that upgrading still isn’t automatic. You are going to have to put some time and effort into a conversion project. It is always depressing to have to spend programming hours on a new version of an application which doesn’t offer anything new to the user, but in this case I think it’s essential. The time spent on the conversion will be much less than starting from scratch, and the resulting migrated application will have a future. If you do the job right and use the conversion as hands-on training in VB 2005 techniques, then the new version should be easier to develop in the future.
There is no question that the .NET environment is more productive overall than VB6, which offered an initial acceleration to a project rather than a sustained productivity. Avoid the trap of trying to return to VB6 to fix a problem, and certainly don’t implement your own VB 2005 solutions starting from scratch. The .NET framework classes now represent a huge resource within which you should be able to find what you need. If it isn’t exactly right, then derive your own class from it and customise – make object orientation work for you.
With Visual Basic 2005 it is easier to port older VB programs, but it will never be 100% backward compatible because VB.NET does away with many of the illogical and dangerous features inherent in VB6. To get a better program you have to put some work in. To steal a saying from the eXtreme Programming community – embrace change.
Ian Elliot, a Principal Technologist with I/O Workshops Ltd, has been developing classic VB applications since Visual Basic for DOS. As a result he has a huge collection of applications that need migrating.
Comments