News:

Download Pelles C here: http://www.smorgasbordet.com/pellesc/

Main Menu

Debugger enhancements

Started by dynoroddyD, June 09, 2005, 12:26:59 PM

Previous topic - Next topic

dynoroddyD

I have probably missed this bit in the Help files, but I can't find any way to view data in any format other than hex. I would like to be able to see chars and null-terminated strings as text, and numbers in decimal. (Being able to switch between these formats and hex at will would be even more useful)

I'm almost certain I'm doing something wrong here - I can toggle breakpoints in any window of the IDE, but they only seem to work if I toggle them in the debugger window ... which is only open when the debugging session starts.

Thanks for providing a great alternative to the bloated giants from Borland and Microsoft.

Pelle

Quote from: "dynoroddyD"I have probably missed this bit in the Help files, but I can't find any way to view data in any format other than hex. I would like to be able to see chars and null-terminated strings as text, and numbers in decimal. (Being able to switch between these formats and hex at will would be even more useful)
In Tools -> Options -> Debug tab, you can uncheck "Hexadecimal variable values" to view values in decimal format.
It might depend on the data type, but it is possible to see strings as strings (see attached picture). Maybe you have an example where it's not working?

Quote from: "dynoroddyD"
I'm almost certain I'm doing something wrong here - I can toggle breakpoints in any window of the IDE, but they only seem to work if I toggle them in the debugger window ... which is only open when the debugging session starts.
There is one known bug with breakpoints: if some lines are folded in the source editor, the wrong line numbers will be sent to the debugger. Does this explain it?

Quote from: "dynoroddyD"
Thanks for providing a great alternative to the bloated giants from Borland and Microsoft.
Thanks!

Pelle
/Pelle

dynoroddyD

Thanks for the info on viewing data properly.

Breakpoints work as predicted too. I think there may have been a problem caused by putting the sources in a subfolder, e.g.

d:\projects\thisproject\myproject.ppj
d:\projects\thisproject\sources\mycode.c
d:\projects\thisproject\sources\myothercode.c
d:\projects\thisproject\sources\myincludes.h

For some reason, the debugger asks where the source files are. If the files in the above example are all in "d:\projects\thisproject\", everything runs smoothly.

Pelle

OK. I only store the basename of source files in *.ppx files (for breakpoints and a few other things) - I didn't want to store the full path, but a path relative the project directory should work better...

I will look at it.

Pelle
/Pelle

dynoroddyD

Many thanks for the explanation of the problem, and in advance for this potential enhancement.

The reason that I want to split things out is that the projects that my employers work on tend to have several subfolders for sources, e.g.
  longpath/project/
  longpath/project/sources
  longpath/project/sources/includes
  longpath/project/sources/appstuff
  longpath/project/sources/libstuff
  longpath/project/derivedincludes
  longpath/project/logs
  longpath/project/data
  longpath/project/output

This makes it easier to dump off the sources to backup media as an entire tree but omit any derived or intermediate files, e.g. *.OBJ, and data & log files, and then add the few other vital files to the project root, e.g. *.BAT, *.PPJ and *.PPX. Because I have become used to this fairly simple but effective tactic, I tend to use it for my own projects when they become a bit too complex to keep track of in a single folder.