Home Articles Books Downloads FAQs Tips

Debugging packages and components within the C++Builder IDE.

Warning!!!! Before you attempt the techniques explained in this article, save all of your work and continue to save it frequently. This article presents some cool information, but the techniques can lead to instability in the BCB IDE. Use the techniques discussed in this article at your own risk

Creating custom components is a trial an error process. Components rarely work the first time they are compiled. It usually takes several iterations before a component begins to act correctly at runtime. The safest way to test a new component is to add the component unit to a test project. The test project creates an instance of the component at runtime, sets some properties, and then exercises the control to test how it behaves. Once the component behaves correctly at runtime, the next step is to add the component to the C++Builder IDE. This step usually exposes some weaknesses in your control. Maybe the control doesn't interact with the object repository correctly, or perhaps it generates an access violation when the user deletes the control from the form.

If you have encountered these design time problems in the past, you may have thought that there was no way to debug your component at design time in the IDE. Wouldn't it be great if you could put a breakpoint in the destructor of your component that gets tripped when the user removes the control from a form? Well, you can, and this article shows how you can do it.


Debugging a package

Recall that there are two types of packages: runtime packages and design time packages. All packages are essentially DLLs with some added features. C++Builder allows you to debug both packages and DLLs. In fact, the debug process is practically identical for the two, since packages and DLLs are one in the same.

In Win32, all DLLs run in the address space of the process that loaded them. To debug a DLL, you must first execute a program that loads the DLL. This program is called the host application. The C++Builder 3 IDE allows you to debug DLLs, but before you start debugging, you must tell C++Builder the name of your host program. You can do this by opening the DLL project in the IDE. Then select Run | Parameters from the menu. C++Builder displays a dialog box that looks like the picture in Figure 1. After you enter the name of a host program, you can select Run |Run or press F9 to launch the host process. When the program hits breakpoints in your DLL code, the C++Builder will popup the code editor with the break point in view.


Figure 1. Specifying the Host Application


Using the BCB IDE as a host process for a package

Since a package is a DLL, you can debug a package the same way that you debug a DLL. You open the package project in the C++Builder IDE, select Run | Parameters from the menu, and specify the filename of the host application. Now here's the trick. If you want to debug a design time package, simply specify BCB.EXE as the host application. That's it! Find the full path to BCB.EXE and enter this filename in the Host Application entry box.

After you specify BCB.EXE as the host application, select Run | Run or press F9 to debug the package. C++Builder launches another instance of C++Builder that acts as the host. The host instance loads your design time package. At this point, you're in business. Go back to the first instance of C++Builder and put breakpoints in the code for your control. Then use the host instance of C++Builder manipulate the control so you hit the break points.


Notes and Suggestions

Note 1: Make sure that you don't try to execute a program from the host instance of C++Builder. In other words, don't press F9 from the second instance of BCB. You can only debug one program at a time, and trying to debug from BCB when you are in the middle of debugging that instance of BCB just causes havoc. In fact, don't press F9 at all. It's too easy to lose track of which BCB program has the input focus. I suggest that you use only toolbar buttons or menus to step over code.

Note 2: When I debug a simple component, I initially trip over an EResNotFound exception that complains "Resource DBXDBI not found." I'm not sure where it comes from, but it is handled quite nicely internally by BCB, so just run through the exception and all should be ok.

Note 3: As mentioned previously, save your work before debugging.

Note 4: This techniqe works great for packages that plug into the IDE using the OpenTools IDE. In fact, that's how I discovered the technique. My first custom made project expert was crashing on me, and I could not figure out why. I eventually learned how to set up a breakpoint and step over the code of my project expert (I still don't know why the expert is crashing, but that's a topic for another article).

Note 5: Try to debug from Windows NT if possible. If something crashes, you will be more likely to recover on NT than if you run Windows 95, or even worse, Windows 98.

Note 6: You can pass the -ns command line switch to the host instance of C++Builder to prevent the splash screen from appearing when you debug a package.

Note 7: Compiling a project from the host instance of C++Builder might not work all that well either. The host instance of BCB appears to start in the directory where the package project resides. The host instance doesn't seem to know where it's own include and lib files are. You may be able to fix this by specifying fully qualified paths in the project on the host instance. To play it safe, you may be better off by debugging without compiling.

Note 8: If you give this technique a try, feel free to let me know how it turns out.



Copyright © 1997-2002 by Harold Howe.
All rights reserved.