Partager via

Visual Basic Concepts

  • Article

Debugging Limitations for Multithreaded Components

The Visual Basic development environment only supports one thread of execution. To debug the multithreaded behavior of your component, you must run your test application against the compiled component.

Out-of-Process Components

For out-of-process components, this means compiling both the component and the test program, and running multiple copies of the test program. (You can also run multiple copies of the test program using multiple instances of the development environment, but you cannot trace into the compiled component.)

In-Process Components

To test the multithreaded behavior of apartment-model DLLs, split your test program into two parts — a standard executable from which you control the tests, and a multithreaded out-of-process component. The standard executable is a client of the out-of-process component, which in turn is the test client for the DLL.

For example, the multithreaded out-of-process component might provide a TestMultiThreadDLL class. The standard executable might create varying numbers of TestMultiThreadDLL objects, passing each one a set of test parameters and then calling its BeginTest method.

The BeginTest method should enable a code-only timer, as demonstrated in "Creating an ActiveX EXE Component," and then return immediately, in order to avoid tying up the single-threaded Standard EXE. The TestMultiThreadDLL object’s timer would control creation and testing of the objects provided by the in-process component. Each TestMultiThreadDLL object would exercise one thread (apartment) in the in-process component.

Note   To use this testing technique, you must compile both the multithreaded out-of-process component and the DLL.

Using a Native Code Debugger

If you’re compiling your component to native code, and you have Microsoft Visual C++, you can compile your component with symbolic debug information for the Visual Studio debugger, which supports multithreaded debugging.

Debug Messages

Because you can’t debug multithreaded behavior in the development environment, you can’t use Debug.Print and Debug.Assert to show debug message strings.

You can’t use message boxes to show debug messages, either, because the Unattended Execution option completely suppresses user interaction.

Approaches to sending debug messages include:

  • Create a single-threaded ActiveX DLL (that is, one that’s not marked for unattended execution) with a public, creatable class that displays a modeless form with a list box. Give the class a DebugMsg method that takes a string argument and adds it to the top of the list box.

    You can call this single-threaded DLL from any thread in your multithreaded ActiveX EXE project. The calls will be slow, because of cross-thread marshaling (as described in "Designing Thread-Safe DLLs"), but this is not a big concern when you’re debugging.

Tip   Include the ThreadID in your debug message text.

  • Create a single-threaded out-of-process component that works in the fashion described above.

  • Create a program that handles Windows messages, using the AddressOf operator to subclass a Visual Basic form. Use the Windows API to create and register private messages which the component you’re debugging can use to send debug strings.

For More Information   Compiling to native code is discussed in "Compiling Your Project to Native Code," in "More About Programming," in the *Visual Basic Programmer’s Guide.*Subclassing windows with the AddressOf operator is discussed in Accessing DLLs and the Windows API, in the Component Tools Guide.