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.
Is VB.Net stable enough to use?
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.
|