Visual Basic used to be, by far, the most widely used development language in the programming universe. It was the development environment that took Microsoft Windows (and Microsoft themselves) to complete market dominance. It was the simplicity of the language and the ease in creating applications that drove this success, and the power of the debugging tools were a major factor in this. Visual Basic debugging tools were the best in class, and even now, they are as good as any debuggers out there. By the end of this tutorial you will understand how to debug in Visual Basic, what tools are provided and the tutorial provides helpful tips on getting the most out of the Visual Basic debugging environment.
Before I developed in Visual Basic, debugging was a major chore. Every application has bugs and tracing those bugs was a real laborious painstaking task. I’m not saying that fixing bugs in Visual Basic s any easier, but finding the bugs with the tools available is much easier. As any developer knows, finding the bug is half the battle! Debugging in all VB.NET editions such as Visual Studio 2010, 2013 or Visual Studio Express is essentially the same process. Conceptually the process and the tools provided are the same.
Out of the box, Visual Basic has a debug tools:
- Command Window
- Watch Window
- Locals Window
- Call Stack
Let’s look at each of these in turn
If, like me, you’re all fingers and thumbs when you type then Intellisense is your friend. Visual Basic Intellisense will check if what you’ve typed is valid as you’re typing! For example, Visual Basic variable names can be lower and upper case. When you type and forget to capitalise a letter, Visual Basic will capitalise it for you. When you mistype a variable name or keyword, Visual Basic will tell you by putting a red line under the word. Visual Basic is essentially spot checking your code for mistakes as you type! It will warn you if variables aren’t used in a routine. It will even warn you if you try to assign a value of the wrong data type to that variable. I don’t know how many hundreds of hours Intellisense has saved me.
Perhaps the coolest thing about Intellisense is its ability to autocomplete. When you type the name of a Function, it will list all the parameters that need to be passed to that Function. When you type the name of a control, it will list all the properties and methods available to that control. Autocomplete is ubiquitous on smartphones these days but back then it was a revolution, the difference being, this autocomplete works!
Perhaps the biggest revolution in debugging was and remains the ability to set a breakpoint on a line of code. When Visual Basic runs and encounters this line of code, it simply stops executing. You’re in Break Mode. Let’s try that.
Open up the For Loop project, put a breakpoint on any line by pressing F9. Run your project. When Visual Basic breaks on that line, you can single step through your application, one line at a time. To execute that one line of code, press F10. Visual Basic will execute that one line, stopping at the next line. You can execute your entire application one line at a time! You can even check the values of e.g. your variables one line at a time by hovering your mouse over that variable. You can see the state of your application, line by line. Genius!
When in Break Mode you’ll see the Watch Window by default in the bottom left of your screen.
The Watch Window allows you to monitor variables or expressions e.g. variable = some value. You can set Visual Basic to just Watch the expression and quickly view the value when you reach a breakpoint. I have to be honest, I don’t use this feature so much but it’s lasted from Visual Basic 3 so there must be some people out there who like it.
The Immediate Window is probably my favourite of all the debugging windows. When in break mode I can call Functions (as shown above) or use the Debug Object to view the value of variables or expressions, and I can even change the value of variables at runtime. For example, I can use type Debug.Print variablename (Or ? variablename for shorthand) and Visual Basic will show me the value of that variable. I can enter a full expression such as Debug.Print variableone > variabletwo, and Visual Basic will tell me if that expression is true or false. Entering Debug.Print variable1/variable2 will give me the answer there and then. You can write code to check your code! I use this window all the time.
There is some overlap (and confusion) with the Command window. Essentially the Command window is a command line tool in itself. It is possible to e.g. search & replace text in a project or call any of the menu items. You can also debug with it, however for debugging purposes just stick to the Immediate Window. That’s what it is for.
The Call Stack probably my second favourite window as it shows exactly what code has been called before that break point. You can see essentially the entire flow of execution of your program. You can see instantly if the program is behaving and executing as expected. Double clicking a routine name will take you directly to that routine (if it is your code) which can be extremely useful.
The Locals Window allows me to drill into all the variables and objects in scope at that time and view their values. This can be an invaluable timesaver if you can’t remember that variable name exactly. It also shows exactly what is in scope at that time.
So there you have it, you have a wealth of tools at your disposal. Use them wisely and they can be a terrific timesaver.
To see these tools in full swing view the following video