📄 pkgdbg.htm
字号:
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD><TITLE>Debugging packages and components within the C++Builder IDE.</TITLE>
<META content="text/html; charset=gb2312" http-equiv=Content-Type>
<META content="Harold Howe" name=Author>
<META content="Microsoft FrontPage 4.0" name=GENERATOR></HEAD>
<BODY>
<CENTER>
<TABLE border=0 cellPadding=0 cellSpacing=0 width=640>
<TBODY>
<TR>
<TD>
<H3>Debugging packages and components within the C++Builder IDE. </H3>
<P><B>Warning!!!!</B> 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 </P>
<P>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. </P>
<P>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. </P>
<UL>
<LI><A href="pkgdbg.htm#debug">Debugging
a package</A>
<LI><A href="pkgdbg.htm#ide">Using the
BCB IDE as a host process for a package</A>
<LI><A href="pkgdbg.htm#notes">Notes and
Suggestions</A> </LI></UL>
<P></P><BR>
<H3><A name=debug>Debugging a package</A> </H3>
<P>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. </P>
<P>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. </P><IMG align=bottom border=0
src="images/runparam.gif" width="438" height="193"> <BR>
<H4>Figure 1. Specifying the Host Application</H4><BR>
<H3><A name=ide>Using the BCB IDE as a host process for a package</A>
</H3>
<P>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. </P>
<P>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. </P><BR>
<H3><A name=notes>Notes and Suggestions</A> </H3>
<P><B>Note 1:</B> 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. </P>
<P><B>Note 2:</B> When I debug a simple component, I initially trip over
an <TT>EResNotFound</TT> 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.
</P>
<P><B>Note 3:</B> As mentioned previously, save your work before
debugging. </P>
<P><B>Note 4:</B> 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). </P>
<P><B>Note 5:</B> 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. </P>
<P><B>Note 6:</B> You can pass the <TT>-ns</TT> command line switch to the
host instance of C++Builder to prevent the splash screen from appearing
when you debug a package. </P>
<P><B>Note 7:</B> 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. </P>
<P><B>Note 8:</B> If you give this technique a try, feel free to let me
know how it turns out. </P></TD></TR></TBODY></TABLE></CENTER></BODY></HTML>
⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -