Beating the VB IDE into Submission


Desktop-as-a-Service Designed for Any Cloud ? Nutanix Frame

Visual Basic was created as a rapid application development (RAD) tool, yet the default IDE settings of Visual Basic do not lend themselves toward effective coding and often result in unnecessary time wastage.

It took me a while to get Visual Basic to behave the way I wanted it to, but eventually I got there. Working with Visual Basic is now a pleasure in comparison to what it was the first time I installed it. Now, every time I work on a machine other than my own, the VB IDE just gets infuriating.

I thought I would share some of these "tricks" with you. Some are about setting up the IDE and others are just ways of coding which work for me.

IDE Settings

Dim or Dim-wit?

Ah, the battle rages on as to whether or not to force one's self to use declare all variables before they can be used. I'm sure any one who has used Visual Basic for any amount of time will know the debate over the Dim statement. Let me outline the advantages for both sides of the argument, and then you can make an informed decision yourself.

For variable declaration:

You won't spend hours tracking down a spelling mistake in a variable.
Variables can be declared in multiple scopes all sharing the same name.
Best coding practices all suggest using it.

Against variable declaration:

It can save about three seconds per variable (but could spend hours debugging a spelling mistake).
...that's about it.

Guess which one I subscribe to! Yet, with everything pointing toward forcing variable declaration somehow Microsoft still thought it would be a good idea to turn it off.

So, the first thing I would suggest in VB is to set the "Require Variable Declaration" setting found under "Tools -> Options... -> Editor".

Auto Check Syntax

Once you have used Visual Basic quite a bit, you'll start to find that that flipp'n popup (that appears each time you move off an incomplete line) starts to get really annoying. For example, if you type "if then" and move your cursor off this line, a warning pops up telling you it is an illegal statement.

You can prevent this popup up unchecking the "Auto Syntax Checking" setting. This setting shouldn't be used by beginners because it often helps you to quickly identify incorrect syntax, but after you've been using VB for a while it is time to let it go.

Compile On Command

Found under "Tools -> Options... -> General," the "Compile On Demand" setting has to be one of the most infuriating settings in VB. In a nutshell, what it does is, when running code from the IDE, a line of code is only compiled once it is reached, which sounds like a good idea... at first. But, what happens is, you are nicely stepping through you code and then BANG, it breaks because there is an error on the line you have reached. So, you correct the error and then start again with your testing.

Plus, any code you never reach (for example, error trapping) doesn't get compiled, so you never see some error creep in. To see what I am talking about, try the following. Make sure "Compile On Demand" is on and then make a new project, inside which you place the code:

Private Sub TestProcedure()
End Sub

This shouldn't work because "hello " is not defined. But, run the code and it works fine. At least, it will work until you reach this procedure. Only then will it complain.

On the first big piece of code I wrote, everything seemed to work and so I decided to build my exe. But once I did, it took ages to go through all of the bugs that had crept into my code.

These headaches can be avoided by turning off "Compile On Demand." It doesn't take a machine long to compile your program, and the saving at the end of the day is worth every last millisecond.

Beating the VB IDE into Submission


Desktop-as-a-Service Designed for Any Cloud ? Nutanix Frame

Useful Plugins

Mouse Scroll Wheel

The singularly most annoying thing about Visual Basic has to be the inability of being able to use the mouse scroll wheel.

But, thanks to Ulli Muehlenweg, there is a solution. You can download a pug-in that adds mouse wheel support to the VB IDE from Planet Source Code. Just download the code. Compile the DLL and copy it to the Visual Basic folder. Then, inside the IDE, load the plug-in. (You can load this plugin by going to Add-Ins -> AddIn Manager and making sure the "Loaded/Unloaded" and "Load on Startup" checkboxes are checked.)

The only thing to note is that this plug-in does not work if Visual Basic is in SDI mode.

API Viewer

If you use the API at all, I highly recommend downloading a program called API viewer. This program is similar to API Text Viewer (that ships with Visual Studio 6.0), but includes additional API functions. It is also somewhat easier to use, and produces more correct VB code than API Text Viewer.

It can also be configured as a plug-in for VB so that you can access it quickly from the IDE, although I don't find that particular feature too useful. In addition to VB 6.0, it can also be used to access API functions from VB.NET and C#.

API Viewer can be downloaded from www.activevb.de. Thanks must go to Christoph von Wittich for this prog. Das ist ze goed.

Folder Structure for VB Projects

I have a specific folder for storing my VB projects in. I found the structure of it to work pretty nicely most of the time.

One of the things this structure includes is a folder for storing all of my general purpose modules, classes, and forms which I write. For example, I have several of the API functions wrapped in VB modules. This is especially good for operations that require several API calls (for example, reading for the Registry). When I need a function to read from or write to the registry, I simply include the "modRegistry.bas" module from this folder in my project and straight away have instant access to its functions. By constantly re-using these files I make sure they stay up to date, and any changes I make are reflected through out all of my projects that include that module. This leads to a library of well maintained re-usable code.

There is a draw back to this, though. Because not all of a project's files are in the same folder, copying the project does required a bit of admin work.


To make more efficient use of the MSDN, one needs to decrease the amount of pointless information that one must sift through to get the answer you need.

So, what do you need to do to improve the use of the MSDN? Firstly, decide what information will be useful to you when you are looking for help. Secondly, define a new subset of information to refine your searches. Yes, there is the Visual Basic subset, and you can use it only. But, there is so much more useful information in the MSDN that is just never used because it is not presented to users.

I would recommend including the following sections in your new subset:
First and foremost the "Visual Basic Documentation" (obviously)
The "Platform SDK" section that helps you with API calls.
Finally, the books "Advanced Visual Basic" and "Hardcore Visual Basic"

To define this new subset, go to View -> Define Subset... In the dialog box presented, expand the "MSDN Library Visual Studio 6.0" heading, select "Visual Basic Documentation," and click "Add>." In the same way, add "Platform SDK" (not "SDK Documentation;" it's not so useful). Then, expand "Books" and add "Advanced Visual Basic" and "Hardcore Visual Basic" to the subset. Give the subset a new name (I use "Adv VB") and click OK. Then, in the Active Subset drop-down, select your new subset.

You should find your help more useful now.

Beating the VB IDE into Submission


Desktop-as-a-Service Designed for Any Cloud ? Nutanix Frame

Coding Practices


To quicken your coding with VB, the biggest trick is to get into the habit of using Intelllisense, which auto-completes variable and function names. Just like when you type the name of a control, a drop-down list appears with all properties and events, so you can get the same drop-down list at any time. All you need to do to get this drop-down is press Ctrl+Space.

So easy, but I am always amazed by how few people even know about it.

Error Trapping

Error trapping is very badly implemented in VB. You have to use GOTO statements to achieve error trapping; there is no "Try ... Catch" as in C++. I have often been faced with the problem of dealing with errors and how to go about fixing them. At first, I used the standard method of "On Error Goto Err_Handle1", then defined Err_Handle1 at the bottom of my code... but you don't even want to know the number of times I forgot to put in the Exit Sub before my error handling, and so normal operation ran straight into error handling code.

I subsequently have found a much better approach (but please note that, every so often, I do encounter the odd situation where I can't handle it this way). I now use "On Error Resume Next". After any positions where I expect an error, I place a test for it, and then I turn error trapping off. This allows me to handle errors just like a try ... catch. For example, consider the case where you want to dynamically add elements to an array. Here is a great way to go about it:

'Turn on error trapping
   On Error Resume Next

   'Attemptto resize the array.
   'The command Ubound() generates an error if the array
   'has not yet been dimensioned
   Redim Preserve MyArray(Ubound(MyArray) + 1)

   'Test for an error (You may even want to check for a
   'specific error number rather than not 0)
   If Err.Number <> 0 Then
      'Initialise the array
      Redim MyArray(0)
      'Clear the error
      End If
   'Turn off error trapping
   On Error Goto 0

   'Write the required value into the last element of the array
   'Won't generate an error as the array has now been dimensioned
   MyArray(Ubound(MyArray)) = Value

I use this method for many different situations, but as I said, sometimes it isn't viable.

Variants and Variable Declarations

This is a fairly pretentious issue. Should one ever use variants or should all variables be declared with their associated data types? This is not easily answered. My honest answer is that I don't know which is better... in fact, I don't actually think there is a right or wrong answer. But, I can give you both sides of the argument.

The original basic language was designed such that there were only numbers and strings. The designers didn't want programmers to have to worry about whether a variable was an integer or a real, or whether two or four bytes should be used to store this number. I am sure that, had they (the designers) encountered variants when constructing basic, all variables would have been stored as variants exclusively. After all, what would be more basic than just storing information rather than worrying about what kind of information it is?

However, each variant requires at least 16 bytes to store any data type. So, if you store a byte, you are effectively wasting 15 bytes. Add to this the extra processing required to manage variants. Each time data is written to or read from a variant, additional processing must manage the content and headers of the structure.

Conversely, if one is using Visual Basic, speed should not exactly be of primary importance (else, you would rather use C++). After all, VB should only be used for GUI stuff, not highly intensive processing. In which case, whether it takes 5 or 20 milliseconds to display a form, who cares? Plus, memory nowadays is a readily available commodity to programmers. Is anyone really going to miss the extra 15 bytes you used?

Now, don't get me wrong, I do not advocate using variants (I prefer my code to be as efficient as possible), but I can well understand the arguments for using variants.

I also should point out that I once had a problem using variants in VB Script. I stored a number from a text box in a variable and compared it to a number from a database. My code just would not work. Eventually (many hours later), I tracked it down to the fact that the value from the text box was a string and the value from the database was an integer, but VBScript's variants did not do the necessary conversion between the types, and so thought that they were different. I am pretty sure that VB 6.0 manages its variants better than VBScript, but I point it out anyway.

My affinity for using typed data has also gotten me into hot water. Once, when using the Microsoft Office Charting Web Component, I passed typed data to the chart, but it was expecting variants. No error was generated; it just displayed nothing. It took me ages to work out that typing everything to variants would fix the problem.


  • There are no comments yet. Be the first to comment!

  • You must have javascript enabled in order to post comments.

Leave a Comment
  • Your email address will not be published. All fields are required.

Most Popular Programming Stories

More for Developers

RSS Feeds

Thanks for your registration, follow us on our social networks to keep up-to-date