ArcGIS Engine Developer Guide

THE V ISUAL BASIC 6 DEVELOPMENT ENVIRONMENT
DEBUGGING VISUAL BASIC CODE
Visual Basic has a debugger integrated into its development environment. This is,
in many cases, a valuable tool when debugging Visual Basic code; however, in
some cases it is not possible to use the VB debugger. The use of the debugger and
these special cases are discussed below.
Running the code within an application
It is possible to use the Visual Basic debugger to debug your ArcObjects softwarebased
source code even when ActiveX DLLs are the target server. The application
that will host your DLL must be set as the Debug application. To do this,
select the appropriate application, ArcMap.exe, for instance, and set it as the Start
Program in the Debugging options of the Project Properties.
Using commands on the Debug toolbar, ArcMap can be started and the DLL
loaded and debugged. Break points can be set, lines stepped over, functions
stepped into, and variables checked. Moving the line pointer in the left margin
can also set the current execution line.
Visual Basic debugger issues
In many cases, the Visual Basic debugger will work without any problems; however,
there are two problems when using the debugger that is supplied with
Visual Basic 6. Both of these problems exist because of the way that Visual Basic
implements its debugger.
Normally when running a tool within ArcMap, the DLL is loaded into ArcMap
address space, and calls are made directly into the DLL. When debugging, this is
not the case. Visual Basic makes changes to the registry so that the class identifier
(CLSID) for your DLL does not point to your DLL but, instead, points to the
Visual Basic Debug DLL (VB6debug.dll). The Debug DLL must then support all
the interfaces implemented by your class on the fly. With the VB Debug DLL
loaded into ArcMap, any method calls that come into the DLL are forwarded to
Visual Basic, where the code to be debugged is executed. The two problems with
this are caused by the changes made to the registry and the cross-process space
method calling. When these restrictions are first encountered, it can be confusing
since the object works outside the debugger or at least until it hits the area of
problem code.
Since the method calls made from ArcMap to the custom tool are across apartments,
there is a requirement for the interfaces to be marshalled. This marshalling
causes problems in certain circumstances. Most data types can be automatically
marshalled by the system, but there are a few that require custom code because
the standard marshaller does not support the data types. If one of these data
types is used by an interface within the custom tool and there is no custom marshalling
code, the debugger will fail with an “Interface not supported” error.
The registry manipulation also breaks the support for component categories. Any
time there is a request on a component category, the category manager within
COM will be unable to find your component because, rather than asking whether
your DLL belongs to the component category, COM is asking whether the VB
96 • ArcGIS Engine Developer Guide