Click to edit watch items?

[dmoore]

Is there a reason not to just be able to click on a watch item and have it become editable? (i.e. why do i need to right click -> "rename"?)

[oBFusCATed]

wxPropertyGrid doesn't allow us to do it. You can hit Insert to edit the selected watch.
Double clicking is meant for expand/collapse.

[dmoore]

Yeah a quick look at the docs seems to confirm. Insert not very discoverable but good enough now that I know.

Btw, is it intended that hitting del on "Locals" removes the special locals (and its children)?

[oBFusCATed]

I'd rather use f2, but it is not possible, because it is used for something else and wx doesn't allow local accelerators.

Btw, is it intended that hitting del on "Locals" removes the special locals (and its children)?

No, exact steps to reproduce please.

[dmoore]

Btw, is it intended that hitting del on "Locals" removes the special locals (and its children)?

No, exact steps to reproduce please.
[/quote]

Start debugger, and hit a break point. Click on "locals", click it again so that it receives focus, press del key. Can do the same for function args.

[oBFusCATed]

Bleh, this shouldn't have been possible 

[dmoore]

I like the locals feature though. I just implemented it for my python debugger.

[oBFusCATed]

Fixed in trunk.

For gdb's debugger locals/func args are almost unusable for real world projects (debugging c::b for example).

[dmoore]

Because of speed? I noticed the C::B takes a long time to update the watch between steps, but wasn't sure that was the reason.

Performance is pretty good for python, but I only enumerate and update the children of items (including the locals item itself) if the item is expanded and I truncate long strings of data on the python end to minimize whatever bottleneck occurs when transferring long strings back to C::B. I also had to recategorize locals into functions, classes, modules, and other because everything is an object in python.

[oBFusCATed]

Because of speed? I noticed the C::B takes a long time to update the watch between steps, but wasn't sure that was the reason.

Yes, the PipedProcess class is very slow when there are tons of lines. This is the major bottleneck.

I also had to recategorize locals into functions, classes, modules, and other because everything is an object in python.

Can you show a screen shot, by the description it sounds that it is too cluttered, but it might not be the case.
I suppose I should try your debugger. Where are the most recent sources?

[dmoore]

Github... (see my sig)

To compile, use the all target if building against self compiled C::B, otherwise use the cbplugin target to build agaibst system installed.

To use, just open a python script and start debugging (no project target support yet)

[oBFusCATed]

I'd rather implement some autotools support for it, because this is how I build my plugins I use with C::B.
If you're interested you can look how I've done the gdbmi plugin, it is pretty simple and straight forward (for autotools)

Do you support attaching to running applications?

[dmoore]

Re attach to process, not yet. rpdb supports this but it's a bit of work.

I doubt I will have time to set up the autotools stuff any time soon. Would be nice if we had a script that could generate the files from a plugin's cbp.

[dmoore]

I'd rather implement some autotools support for it, because this is how I build my plugins I use with C::B.
If you're interested you can look how I've done the gdbmi plugin, it is pretty simple and straight forward (for autotools)

Have you looked at cmake? Among its many nice tricks is its ability to generate Code::Blocks project files. (Would like to see more C::B integration with cmake, but unfortunately I don't have the time any time soon)

[oBFusCATed]

Have you looked at cmake?

No, but we might start using it at my company, so I'll probably have, too.

Among its many nice tricks is its ability to generate Code::Blocks project files.

Last time I've tried it, it just generated makefile based projects, not proper projects.