|< Free Open Study >|| |
The Visual Studio .NET IDE is much smarter than previous versions of the VB IDE. One of the great improvements is that Visual Studio .NET automatically underlines any error, with respect to objects, type casting, and so forth, that it knows will fail at runtime. For example, Figure 4-3 shows an IDE error notification.
Figure 4-3: IDE error notification
You should always look for this indication of an error, especially in new code. It will save you from having to wait while the compiler compiles your program, only to respond that you have a failure to compile successfully. Perusing all new code for underlined code will save you much wasted compile time. When you place your mouse cursor over the underlined code, Visual Studio displays a tool tip denoting the cause of the error.
An even more helpful tool for finding error information is the Task List window. This is new in Visual Studio .NET, at least for VB users. The Task List window normally appears at the bottom of the IDE, and its caption bar always contains the number of errors that the IDE knows about in your code displayed in the form "0 Build Error tasks shown (filtered)". If the number is something other than "0," you have an error somewhere in the code. If this is the case, the error will be listed in the body of the Task List, and you can go directly to the error by double-clicking it. So to keep from wasting time compiling when the IDE already knows that you have errors, always ensure that the number of Build Errors shown is 0.
Visual Studio by default creates new modules or classes with Option Strict On. This means that the IDE will automatically underline a line of code that will either compile or fail at runtime. This is a great improvement over earlier versions of Visual Studio. I strongly recommend that Option Strict always be left on.
There are caveats when using Option Strict On, of which I will mention just a couple. First, late binding is not allowed. Second, you cannot use the concatenate operator (&) to concatenate a value to an object. This is a problem when storing database fields into a variable. To prevent raising an error if a String field is null, the practice in VB 6.0 is to concatenate a vbNullString to the field value. Option Strict On will not permit this type of code.
What I mean by this section's heading is that you must be constantly aware that you can no longer change code in the debugger and execute the changed code. I know I have mentioned this several times already, but it is a real disadvantage, and you must look for ways to work around it when you can. Fortunately, there are a couple of ways to work around this reduced functionality in the debugger. First, you can change the code, assuming you set the correct options as previously discussed. Once you have changed a line of code, it will still execute, but stepping through the line will execute it as it was coded originally. However, you can execute the changed line by copying it to the Immediate window and executing it there. Then, right-click the next line of code and click the Set Next Statement option to execute the line following the changed line.
This method will not always work, especially when system objects are involved. It will work on simple instructions that are storing into a string or scalar variable, for example.
Second, use variables to contain values rather than including a string or number value in a line of code. If you are going to have strings or other values that could require changing at runtime, always Dim and set a variable instead of coding the string or other value into a line of code.
How will that help you? Here is an example:
Dim iBitMap As Integer iBitMap = 59 CommandObj = oVB.Commands.AddNamedCommand(objAddIn, _ "MyAddinTest1", "Smart Desktop", _ "Executes the command for MyAddinTest1", _ True, iBitMap, Nothing, 1 + 2) _ '1+2 == vsCommandStatusSupported+ _ ' vsCommandStatusEnabled CommandObj.AddControl(oVB.CommandBars.Item("Tools"))
In this code snippet, iBitMap is an integer that indexes to an icon in Office.DLL. After seeing the icon on your menu, you may decide that you want a different icon. Without recompiling the add-in, you can simply disconnect the add-in and set a breakpoint on the line following the highlighted line of code. When you reconnect the add-in, it will stop on the breakpointed line. Then you can go to the Immediate window and execute the following line of code:
IBitMap = 110
Now the value of iBitMap has been changed to point to a different icon and you effectively have changed the code in debug mode without having to rebuild your add-in. This is a very simple example, but if you apply it across the application, you will be able to test different options, strings, and so forth without having to rebuild your application.
I have already discussed this at length, but add-in debugging can be hard enough without letting code run rampant and then viewing the results, only to discover that your add-in has made a mess and you have no idea why! If you are not in the habit of stepping through complex code, trust me, trying my approach to debugging will save you untold hours of headaches.
In addition to stepping through complex code, I use breakpoints generously. I like to know where the code is going at all times. Setting breakpoints at the beginning of complex code segments before you begin debugging is a great way to progress through a debugging session in an organized manner.
Another nice new feature of .NET is that breakpoints are saved when you exit .NET and restored in the code the next time you open the project for debugging. This is a muchneeded addition to the debugger.
|< Free Open Study >|| |