Visual Basic Programmer

MICROSOFT VISUAL BASIC PROGRAMMING

Why Visual Basic.Net?

Here is a series of questions that provide a background to Visual Basic.Net. The answers highlight the problems and opportunities facing the Visual Basic programmer in using the brand new Visual Basic.Net.

How different is VB.Net?

VB.Net is a complete rewrite of Visual Basic 6. The syntax is still almost "Visual Basic" as we know it, but everything else has changed. It now has all the functionality of "C", "C++" or "C#".

VB.Net is not VB6 with some enhancements. It is a completely different Object Oriented language incorporating Encapsulation, Inheritance and Polymorphism. Compatibility with VB6 has been well and truly broken.

Is VB.Net easy to learn?

Visual Studio.Net incorporates Web projects and Web Services, new areas that need specialization. ADO.NET is not simply a new Version of ADO, but a complete rewrite. VB.Net Deployment now uses Microsoft Windows Installer – more powerful, but completely different to VB6 Deployment. The new printing facility of VB.Net provides enormous power with its functionality, but the simplicity of VB6 has been lost.

 The latest release, Visual Studio 2008 has even more features. There is now AJAX, LINQ, WPF, JavaScript, CSS Intellisence, etc, etc to learn. Together with Object Orientation, all these aspects involve a huge learning curve.

It is difficult for the Visual Basic Programming neophyte to learn – especially as VB.Net is so vast and is evolving so rapidly.

The Help system is shockingly bad. There are now some VB.Net examples, instead of only C# examples – but C# is dominant. There is still too much that is at a low-level and esoteric. Defining how a procedure gets Overloaded in 40 different ways is not my idea of documentation.

Thankfully, there is a very active VB.Net community. The Internet is beginning to become a source of information on Visual Basic.Net. The trouble is trying to work out what is current and what has been superseded. Most books on Visual Basic.Net are half-baked, and rushed out to print too quickly.

The current Version (Visual Basic 2008) is a huge improvement over the previous release. VB.Net produces code that is stable and is completely acceptable. The IDE still needs to be made more efficient. AJAX is immature

For the latest news on Service Packs, see the example on RSS Feeds.

How long will support for VB6 continue?

For VB6 users, support ends in 2008. In reality, Microsoft has already stopped support. VB6 will never get support in 64-bit environments. All MSDN library CDs only have VB.Net examples. There will no longer be any VB6 Service Packs or fixes. The latest Windows security updates are aimed directly at Visual Studio.Net, and can invalidate some VB6 routines.

Microsoft is committed to supporting the VB6 runtime on Vista for the next 10 years (although installing VB6 on Vista can be problematic). It is impossible to ignore the advent of VB.Net. Like VB3, the VB6 routines will become harder and harder for programmers to maintain. Planning for the adoption of VB.Net should start now.

How helpful is the VB.Net Upgrade Wizard?

• It does not ensure a 100% upgrade.
• Its output will "sort of" run. But you need to resolve a multitude of Upgrade problems.
• It uses a code standard that is difficult to maintain. Control arrays are now handled, but the code is difficult to support.
• Some of the "fixes" of the Wizard are esoteric and non-maintainable. The "< ... >" construct may work, but is difficult to maintain.
• The Upgrade uses the old VB6 controls, with massive amounts of warnings on potential problems, differing Events and Methods.
• The conversion of Resizing functions work, but is difficult to maintain. Using the new Anchor/Docking involves a redesign of the Form.
• The Upgrade Wizard is a poor learning aid - it does not produce up-to-date examples.
• Upgrades of the VB6 APIs are messy, and not recommended. There is always a VB.Net alternative.
• The conversion will be problematic for any system of non-simplistic size. The Upgrade Wizard produces code that involves a lot of cleanup work.

To get a "clean" version of the code, it is necessary to start a new project from scratch, and use the minimum of the "converted" code.

What technical issues are there in using the VB.Net Upgrade Wizard?

• "Option Strict" should be enforced, and all Upgrade Warnings resolved. All VB6 controls should be upgraded to the VB.Net equivalent. The alternative is to have a project that sort of works, has Event problems, messy code and is difficult to maintain.
• In order to avoid maintenance problems with non-supportable code and hidden constructs, each project must be coded from scratch. Each Form should be reconstructed from the conversion attempt, with a simple Copy and Paste.
• The old Error Handling techniques can still be used – On Error, Resume Next, etc. VB.Net uses a structured approach with Try, Catch, Finally. The major advantage in using the new approach is that error details can be extracted automatically – including error line number, module and procedure names. There is no equivalent of Resume Next and App.Revision does not exist.
• The conversion of FileSystemObjects is problematic. It is best to start from scratch using the new System.IO Namespace.
• Conversion of the old Windows API routines is difficult. It is best to maintain the old code in a DLL, and gradually replace the procedures with VB.Net code.
• Conversion of Events can be troublesome. For example, when double clicking, the Click Event is also invoked first. At start-up, the Click Event is invoked. The Activate Event (now called Activated) is executed before the Load Event, not after. The Finalize Event, unlike the VB6 Terminate Event, takes place on garbage collection (which can be some time later), not when an Object is set to Nothing.
• The String.SubString method seems at first sight to be a very nice replacement for Right, Left and Mid. Unfortunately it crashes when the length field exceeds the size of the string. Definitely not compatible with Right, Left, Mid. Why did'nt Microsoft put in a simple check to avoid this problem????? It is best to stick with the older string handling routines. Use "Imports VB6 = Microsoft.VisualBasic" to make all these VB6 commands easily available.
• The old VB6 Format routines almost (but not quite) work as before. Date handling is different.
• Dividing into an Integer produces a result with decimal places.
• Centring of Forms can be done at design time – the old run-time code should be eliminated.
• All calls use the default ByVal instead of ByRef. So unless ByRef is used, values changed in a procedure will not be returned to the calling routine.
• Conversion of Resizing code will work, but is messy. Forms need to be redesigned to use the new design time docking/anchoring features.
• The VB.Net Deployment is powerful, but complex. Deployment documentation is dreadful.
• Conversions of numeric types to Short should be changed to Integer.
• Setting an Object to Nothing, removes the reference, but not the Object. The Object is removed when the Garbage Collector (GC) gets around to it – and this could take from minutes to hours. It is important to make sure objects that use unmanaged resources (like File Handles, Database Connections, etc) release these resources as soon as possible. VB.Net 2005 provides the "Using" and "End Using" statements to ensure that Dispose() is always called – even if an unhandled exception occurs.
  

What about Data Grids?

Microsoft's DataGrid has all the functionality of the third-party software. It is just as easy to use, if not easier.

• It is free!
• It has an unbound mode. This allows the programmer more control than the bound mode.
• It is easy to create a class encapsulating the control's Object Orientated logic (which is rather esoteric) into simple properties and procedures.
• Microsoft's documentation on the DataGrid is dreadful (as usual), but the Web is now a great source of information.
• The Style of each column can be readily set.
• Font and Colours can be changed – however the standard Grid layout is appealing.

Is it necessary to convert to ADO.Net?

No, it is not essential to convert to ADO.Net – all the old ADO routines are still available. ADO converts reasonably easily in VB.Net. Just remember to set a Reference to "Microsoft adodb 2.7".

You should consider the migration to ADO.Net when there is an efficiency problem. That is when:-

• There are many opens and closes of a database.
• Disconnected database access is required for a Web site.
• There are heterogeneous sources of data.
• There is heavy database activity.

Otherwise, you can keep using the classic ADO routines that you know and love.