BorlandTalk.com

Mark Guerrieri · Guest

BDS2006 SP2-

I can't seem to reliably debug any of my executables. I put a breakpoint
and try to inspect variables, but only reference and built-in types seem to
work. For example, I have the following code as the first line in an event
handler:

void __fastcall TfrmMain::UpdateComboEditActions(TObject *Sender)
{
TAction* a = dynamic_cast<TAction*>(Sender);
if(a == NULL)
return;

a->Enabled = false;

TCustomComboBox* cb = dynamic_cast<TCustomComboBox*>(a->ActionComponent);
if(cb == NULL)
return;

HWND hEdit = FindWindowEx(cb->Handle, NULL, "EDIT", NULL);
....
}

I put a breakpoint on the IF line, and inspect the value of 'a' - The Debug
Inspector shows

a: void :0012E700
Data:

Danzer · Guest

Mark Guerrieri wrote:

Mark Guerrieri · Guest

Ok, I solved the problem- I'll post this here in case anyone else runs into
this.

I routinely change the path/name of the precompiled header file used (under
C++ Compiler Options) to a file in a subdirectory under my project folder,
with the name of my project and a .CSM extension. I do this because I work
with COM/ATL, and compiling frequently produces internal compiler errors
that can oly be resolved by deleting all precompiled header files (*.csm,
*.#xx) and doing a build.

The .#xx files contain centalized debugging info for all symbols in the PCH
file, thus decreasing the size of the OBJ files since debug info is not
duplicated in them.

Unfortunately, if you do not add the path to your new PCH files to the
Linker Options|Paths and Defines|Library Search Paths setting, the debugging
information in those files is never loaded, and they could typically contain
debug symbols for the VCL in you have

#include <vcl.h>
#pragma hdrstop

in your source.

You would typically not notice this problem if you use the default PCH
settings, since the default is to put vcl100.csm in the $(BDS)\lib folder,
which is also, by default, in the library search path.

This seems like a bug to me, since adding the PCH path to any of the Debug
Symbol search paths does nothing, and that would seem more appropriate since
the debug info is loaded dy the debugger and not actually linked into the
app... either way, this should be documented somewhere, and I couldn't find
any mention of a requirement of the linker having to find the debug symbols,
or any warning if it coudn't find them.

Should I put in a QC report for this?

Mark

au · Guest

On Tue, 20 Jun 2006 20:00:29 +0200, Mark Guerrieri
<mguerrieri (AT) ncogroup (DOT) com> wrote:

David Dean · Guest

In article <449837bd$1 (AT) newsgroups (DOT) borland.com>,
"Mark Guerrieri" <mguerrieri (AT) ncogroup (DOT) com> wrote:

David Dean · Guest

In article <44997c0d$1 (AT) newsgroups (DOT) borland.com>,
"Mark Guerrieri" <mguerrieri (AT) no_spam_verizon (DOT) net> wrote:

vavan · Guest

On Thu, 22 Jun 2006 09:49:24 -0400, David Dean
<ozchzhq02 (AT) sneakemail (DOT) com> wrote:

btw anybody noticed that in bcb2006 Reload Symbol Table is _always_
disabled in Modules window or is it just me?

--
Vladimir Ulchenko aka vavan

Mark Guerrieri · Guest