|< Free Open Study >|| |
Debugging an add-in is very similar to debugging a COM object (DLL) in earlier versions of VB. This is because an add-in is a COM DLL. To debug a COM object, you have to have two sessions of Visual Studio running. One will contain the COM object, in your case the add-in, and the second will be a client application that calls or uses the COM object. Again, one of the nicer improvements in debugging an add-in in .NET is that when you press F5 or click the Debug arrow on the toolbar, Visual Studio compiles your add-in, and if there are no compile errors, it automatically starts a new session of Visual Studio from which you invoke the add-in and its associated functionality.
When you start to debug your add-in, Visual Studio .NET may automatically set the flags in the registry, which will cause your add-in to be connected, or loaded, when the second instance of Visual Studio .NET is started. This is all right, and it is not necessary to follow my suggestion here. But what can happen upon occasion is that you will get a diagnostic, or error, denoting that your project files cannot be copied to their destination directory. This happens, apparently, when some part of your debugging session does not shut down properly or clean up itself properly. The only way to recover from it is to first go to the Add-in Manager dialog box and disconnect the add-in. Then you will also probably have to get completely out of .NET and reload your add-in solution.
The best way to prevent this from occurring is to disconnect the add-in in the Add-in Manager in the client (second copy of .NET) that is using the add-in. I call the second copy of .NET the "client," because your add-in is a COM server.
Sometimes, you will not be able to do this, due to the fact that you reach a point in your add-in's code at which you cannot continue. If you have to stop the debugging session in the add-in, the client session of .NET will be automatically terminated because it was automatically started by .NET. At that point, you may be able to prevent any copying problems by going to the Add-in Manager and deselecting the check boxes related to your add-in in the add-in session of .NET.
Again, this whole discussion can be overkill, because if everything goes according to plan and the debugging session is shut down normally, you may never encounter the problem. However, I have come across the problem on numerous occasions, and I wanted you to know what was causing it and how to recover from it or possibly avoid it.
I am going to intentionally try to debug with a known error in the code to show you what will happen. After I press F5 or click the Run button, the compiler, upon finding the error, displays an error dialog box as shown in Figure 4-4.
Figure 4-4: Compiler-detected error
If I click No in the message box asking me if I want to continue with the error, the error(s) will be displayed in the Output window, as shown in Figure 4-5.
Figure 4-5: Errors in the Output window
This example is one of those errors that you could have detected because the variable is underlined, denoting that there is a problem with it. Holding the mouse cursor over the underlined variable will cause the error to be displayed in a tool tip window. Again, perusing new code for the underlined errors is a good, timesaving practice.
Visual Studio .NET has another powerful feature that is new to Visual Basic developers: the Task List. Among other things, the Task List keeps a running list of lines of code that will not compile. You can open the Tasks List by pressing Ctrl-Alt-K. You can also view the Task List by selecting View ⇒ Other Windows ⇒ Task List. The Task List can hold a maximum of 102 uncompilable lines of code. Therefore, you should always look at the Task List before attempting to compile your application. If you double-click any item in the Task List, you will be taken to the bad line of code and it will be highlighted in the code window, as shown in Figure 4-6.
Figure 4-6: Error automatically highlighted in the code window
If you decide to ignore an error, you can click Yes in the dialog box about continuing to debug. When you do that, a second copy of Visual Studio .NET opens automatically.
Now if you go to the Add-in Manager and check both boxes for your add-in, you will get an error and you will not be able to continue debugging the add-in. Visual Studio will ask if you want to remove the add-in from the registry. It does this because it cannot connect to an add-in that will not compile without errors.
At this point, you should answer No to the question regarding removal of the add-in from the registry. In earlier versions of Visual Basic, you had the "Compile on Demand" option, which allowed you to debug parts of a program while there were still compile errors in other parts of the program. Although there doesn't appear to be such an option in .NET, you can ignore the errors in a standard Windows application. You just can't ignore errors in an add-in and expect to get it connected to a client. However, you should note that if you try to ignore errors, even in a standard Windows application, the code beyond the error does not compile, and you won't be able to get to it. Figure 4-7 contains code with an error in it. Note that I have placed a breakpoint on every line following the error.
Figure 4-7: Breakpoints beyond an error line
Next, I run the application, ignoring the errors. Sub Main runs and loads the instance of Form1 (oFrm.ShowDialog), but control never reaches the lines after the line with the error in it. In fact, all breakpoints are ignored, as shown in Figure 4-8, and execution does not even stop on the line that displays the form.
Figure 4-8: Breakpoints ignored in bad code
I think the lesson to be learned here is that in .NET, you must correct your compile errors before attempting to debug your code. In VB 6.0, the ability to compile on demand was a very useful feature at times, but that type of functionality seems to be gone in .NET.
To bring the debugging session to an orderly halt, select Debug ⇒ Stop Debugging or click the Stop Debugging button. This is done in the add-in (server) session of .NET. When you click the Stop Debugging option, the second session (client) of .NET shuts down automatically.
You should always select the Stop Debugging menu option or click the Stop Debugging button in the add-in (server) instance of .NET, rather than closing the second (client) instance manually. Remember that the server instance automatically started the second instance, and it expects it to be there when you finally stop debugging the add-in. If the server instance of .NET does not find the second instance, it prints all kinds of extraneous error messages in the Output window.
While you step through the debugging of an add-in, you can position your .NET sessions and windows so that you can observe what's happening in the client as you execute code in the add-in server. For example, I have a debugging session going in Figure 4-9. I've reduced the size of the IDEs and placed them on top of each other, so that I can observe the action in the client's code window as I step through the add-in. In Figure 4-9, I've stopped the add-in in the PutCodeBack method, which was called by the BlockDelete method. You'll see that execution has stopped just before the block is pasted back to the code window.
Figure 4-9: Just before pasting the deleted block
Next, I've stepped through the selCodeBlock.Paste instruction, and in Figure 4-10, you can see that the paste of the code has taken place and the window has been repainted immediately. Thus, you can see immediately the action that the add-in has effected, as it completes it.
Figure 4-10: Deleted block pasted back to the code window
|< Free Open Study >|| |