Pelles C > Feature requests

Listview under Debug Tabs

<< < (2/2)

John Z:
Fixed!  Seems I just needed to recompile the dll.  I added a few outputs messages anyway. I also
updated the Add-in post with the new project zip.

As promised here are some sample outputs.   
unexpanded shows capture of listview in original state
Few_expanded shows capture of listview with a few items manually expanded using the +

Third file is just another debug tab to show I capture as text whatever is there ....

To me it seemed very helpful to be able to capture the debug output(s) of interest as text so that after
a program change the debug data could be compared to the prior debug data to observe changes. 

Maybe this is not true for others....anyway it was an interesting project too.

John Z

An improvement would be to obtain the tab Name for the output filename  :)
Updated 03/12/2023 removed attachments to save space

Pelle:
I have looked at this now...

Exactly what kind of controls are used by the IDE is really an implementation detail. The debugger symbols are displayed in ListView controls today, but perhaps not tomorrow. The memory dump window is not a standard control at all, and so on.

The proper way is to use the debugger part of the add-in API. Today there are AddIn_EnumDebugGlobals() and AddIn_EnumDebugLocals() for enumerating all global and local symbols. They are pretty low level. What I will do is to add new AddIn_EnumDebugGlobalsText() and AddIn_EnumDebugLocalsText() that will enumerate global and local symbols at a higher level: the callback function will receive a text representation of the symbol Name, Value, Type (plus Address and nesting level) exactly like how the symbols are displayed on the debugger tabs.

Memory dumps can already be handled through AddIn_ReadDebugMemory(), but I will enhance the existing dbginfo.c add-in sample to demonstrate how.


John Z:
Thanks for looking at this.  I hope I've not overstepped my bounds....

My only goal was to be able to provide an easy method to save the tab data generated by the existing Debug
procedures and other tabs below the main window.  I did not intend to change any debugging procedures.

I achieved my goal (except for the Memory tab) but was thinking of an improvement.  It is not necessary and
please don't add or change anything because of this (perhaps) misguided request.

I will look at the Addins you mention and study the Addin_ReadDebugMemory to learn more about it.

I appreciate your time looking into this, my apologies for the non-standard way I used, which I thought was better
than re-inventing the outputs.


John Z

Pelle:
No problem - just trying to save you the trouble of looking for stuff that isn't easily available (like data from the memory dump window).

Using the debugger add-in API will give you all the available data, at the expense of having to format it yourself. This is extra work, but it also means that you can format it any way you like (and write it to a file, send it in an email to Bill Gates... ;) whatever...)

I always try to look at things in a broader perspective, so I think the new AddIn_EnumDebugGlobalsText() and AddIn_EnumDebugLocalsText() could be useful not only to you but (a few) other people as well (it's a reasonable enhancement) ...

Navigation

[0] Message Index

[*] Previous page

Go to full version