Cleaning Up Legacy Code

Cleaning Up Legacy Code

Visual Basic 6 is almost a wonder of compatibility; it maintains code compatibility for many language features going all the way back to Visual Basic 1. These features include elements like DefInt, VarPtr, and GoSub Return that still work, and work reasonably well. But just because they work does not mean that you should use them. These features and others are deprecated in Visual Basic 6, and they have been removed completely from Visual Basic .NET. This section covers the obsolete and deprecated Visual Basic features that you should remove from or replace in your Visual Basic 6 application before upgrading.

VarPtr, DefInt, and Other No-Shows

As we just mentioned, certain language elements are no longer supported in Visual Basic .NET. Some were eliminated because they lead to confusing and cryptic coding styles and are not appropriate for the kind of large-scale distributed application development that is becoming dominant in today s business environment. Others are just no longer meaningful in Visual Basic .NET. Take, for example, VarPtr. Pointers no longer have any meaning in the .NET world. In fact, pointers defeat the purpose of having a runtime environment like .NET in the first place. The runtime frees the developer from various tasks, and any Visual Basic language features that conflict with not only the runtime but also the goal of a scalable language for the enterprise have been eliminated.

These changes are intended to move the language (and the platform as a whole) forward in the most expeditious, and ultimately beneficial, way possible. The following Visual Basic language features are handled by the Upgrade Wizard but are not recommended for use in your applications:

• DefInt, DefStr, DefObj, DefDbl, DefLng, DefBool, DefCur, DefSng, DefDec, DefByte, DefDate, DefVar

• GoTo [LineNum]

• Imp, Eqv

The following features are simply not handled, and eliminating them is left as a task for the developer:

• GoSub Return

• LSet (for user-defined types)

• VarPtr, ObjPtr, StrPtr

• Null and Empty nonzero-lower-bound arrays

Given these changes, where should you start? First you must search out areas in your application that use these language elements and either replace them, or leave them as they are and resolve the issues after you use the Upgrade Wizard. Both approaches are valid. It is often more efficient to fix a problem area before upgrading than to try to sort out the mess afterwards. There are times, however, when no alternatives exist in Visual Basic 6 and the most effective approach is to wait and solve the problem using Visual Basic .NET. This decision is ultimately one that you, the developer, need to make on a case-by-case basis. If you are unsure, it doesn t hurt to run the Upgrade Wizard just to see what it does, but that is a subject covered in a later chapter. (See Chapter 5)

DAO and RDO Data Binding

Over the years, Microsoft has introduced several data access technologies. Starting with Data Access Objects (DAO) and followed by Remote Data Objects (RDO), Microsoft started to bring data access to the masses with an accessible COM-based approach. The big breakthrough was the introduction of ActiveX Data Objects (ADO), with its flexible provider scheme. ADO was designed to provide a generic replacement for both DAO and RDO. It uses OLE DB to interface to various data providers, from comma-delimited text files to Microsoft Access databases to high-end database servers.

Visual Basic .NET introduces ADO.NET as the next generation of data access. Why does Microsoft continue to introduce new data access technologies? It reflects the fact that data access itself is evolving. Writing scalable Web sites is a different programming problem from querying a Microsoft Access database on the local machine. For this reason, ADO.NET s n-tier disconnected data access is very different from DAO data binding to an Access database.

You ll be pleased to know that Visual Basic .NET supports DAO, RDO, and ADO data access code. However, Visual Basic .NET does not support DAO or RDO data binding. What this means is that if your application has DAO or RDO data binding, you should either rewrite it as ADO data binding in Visual Basic 6 or rewrite it as ADO.NET data binding after upgrading the project to Visual Basic .NET.