Page 1 of 1

Problems debugging an ANSI build

Posted: Sat Dec 13, 2008 12:54 am
by coder99
After getting myself sorted out building the ANSI version of a program, I now seem to be having problems debugging that code.
BTW, I've just upgraded to 2527 and for a while thought that might be the problem, but as far as I can tell, it also happens with the earlier versions - at least 2402.
When I move the cursor over top of a variable, instead of the value of that variable, I get the message
"Attempt to extract a component of a value that is not a structure"

This happens for both variables defined in the class as well as local variables.

I may have other problems as well, since the code runs when compiled with MSVC, but not with Codelite. Unfortunately right now, I can't readily see where the problem might be.

Re: Problems debugging an ANSI build

Posted: Sat Dec 13, 2008 1:05 am
by sdolim
Does this happen for any variable? Or only for certain types of variable (like wxString)?

Re: Problems debugging an ANSI build

Posted: Sat Dec 13, 2008 1:46 am
by coder99
The only ones I have verified is wxString - happens, doesn't happen for bools and ints and some structs

Re: Problems debugging an ANSI build

Posted: Sat Dec 13, 2008 3:26 am
by sdolim
OK. I'm thinking that the ANSI build defines wxString differently enough to break the built-in debugger evaluation expression for it.

Fortunately you can change the expression under Settings -> Debugger Settings -> PreDefined Types. (Ignore the SubMenu? item -- it is not implemented.)

I don't have an ANSI build handy, so I can't tell you what the correct expression for wxString is. If you discover it, could you post it here for us?

Scott

Re: Problems debugging an ANSI build

Posted: Sat Dec 13, 2008 4:27 am
by eranif
I believe that simply defining wxString as:
$(Variable).c_str() should be enough

Eran

Re: Problems debugging an ANSI build

Posted: Mon Dec 15, 2008 10:55 pm
by coder99
From a quick look and trial, it looks like that might do the trick. Thank you.

At one point I thought I saw one of the definitions of xxxx.c_str missing the (), but I don't know if it matters.

I suppose this information is kept during a reinstall, so I was not able to confirm it, by simply re-installing.

As I am switching back and forth a lot right now between 4 different configurations to verify that changing one did not break another one, I find it very frustrating not to be able to verify visually and quickly, what the current configuration is - this is most important when one gets interrupted a lot.

This also applies to thing like the debugger settings which seemingly are part and parcel of a particular configuration. For instance, when I change some of these settings, I would find it useful to be able to tell which configuration I am currently inspecting or modifying

Re: Problems debugging an ANSI build

Posted: Mon Dec 15, 2008 11:27 pm
by eranif
So basically what you are saying is that the debugger is not switching configurations as well, right?

Like: When debugging ANSI, use this set of predefined commands, and when debugging Unicode, use second one, correct?

Eran

Re: Problems debugging an ANSI build

Posted: Tue Dec 16, 2008 12:00 am
by coder99
No, not really. The debugger is (seems to be) switching configurations, but I would like to be able to visually see somewhere on the main interface which configuration is currently 'active'.

As far as the debugger setting go, I'm not quite sure if there is one set per configuration or not, nor am I sure whether that is needed since I don't really understand how they are used or. applied

Re: Problems debugging an ANSI build

Posted: Tue Dec 16, 2008 12:03 am
by eranif
There is only one set of predefined types. So, switching configuration may cause the debugger to not display objects as expected (especially wxString)

Eran

Re: Problems debugging an ANSI build

Posted: Tue Dec 16, 2008 12:27 am
by coder99
That might be a problem ;-) for me in any case.

I would like to support OS's before WinNT/XP but Unicode versions of wxWidgets (and others, I assume) need WinNT or better.