Santiago A. wrote

By the way, has anybody managed to debug strings.text or any property with a getter?

I was hoping someone would answer this. I currently insert the equivalent of
sHack := MyStrings.Text;

into code, and watch that.... Means I have to know I want the value of that list before I start debugging...

Ta

Mike

Michael Thompson wrote

I was hoping someone would answer this. I currently insert the equivalent of sHack := MyStrings.Text;

Yes, that is a shortcoming of using the GDB debugger. Currently querying a result of property Getter function is not possible with GDB. You have to store the property result in a variable. Then later delete all such references after debugging (or use your SCM to revert such code changes).

Using GDB has many other shortcomings with the Object Pascal language too. So I often use alternative forms of debugging.

1) I use tiOPF's tiLog unit and can output debug info to Console or File, or what I use most frequent, to a non-Modal GUI window. All logging is cached and happens in a separate thread so doesn't slow down the application.

2) fpGUI contains a modified dbgintf.pp unit, compared to the one included with FPC. I've also written my own GUI Debug Server, also included with fpGUI. So I can log color values and actually see the color in the debug server. I can use "live view" which can show me for example very frequently updated valuese (eg: mouse pointer position) but doesn't cause the debug server content to scroll off screen.

3) I believe there is a Lazarus based debug viewer similar to (2) above. I think I saw some info on that on the wiki once. I can't remember the name though.

Mostly I use tiOPF's logging though (it doesn't require your code to be tiOPF based). I have many code templates set up in my IDE, so adding debug lines (wrapped in debug IFDEFs) are only 3-4 key presses away.

Regards,
- Graeme -

getters are a long way to go still, and if the strings are involved, then even longer.

1) gdb does not support function calls to pascal
2) strings are managed, gdb does not know how to deal with them, if they are needed for function param or result. Special calls to string management are needed or memory will be leaked or corrupted
3) stabs, dwarf2 & 3 do not support encoding the above info
4) Due to 3 fpc can not make that info avail. (maybe later dwarf formats have it)

But often you can find the private variable that holds the value, and watch this.

In Lazarus use the debug INSPECTOR, you can double click any member variables, and go to nested objects etc. Once you found it copy it to watches.

for stringlist you can get all individual strings (but not the text). tstringlist.flist.... somewhere.