Problems debugging an ANSI build

[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.

[sdolim]

Does this happen for any variable? Or only for certain types of variable (like wxString)?

[coder99]

The only ones I have verified is wxString - happens, doesn't happen for bools and ints and some structs

[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

[eranif]

I believe that simply defining wxString as:
$(Variable).c_str() should be enough

Eran

[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

[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

[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

[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

[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.