Suggestion: Debugger inspection templates for complex types

[Lars Fosdal 1792]

I posted the following suggestion on the QP.

https://quality.embarcadero.com/browse/RSP-37096

I wish I could leave hints in the code as to how I would want a debugger to visualize a complex type variable. You add specify it as a watch statement, but you can’t really keep an infinite list of watches, hence a way of describing a default inspection view in the source code would be useful.

 

type
  TEditForm = class(TForm)
    Edit1: TEdit; //$inspect Edit1.(FEnabled, FName, FCaption, Trim(FText))

Consider the hint if you hover over Edit1 in TEditForm.Validate

 

Imagine if the inspect hint comment after the variable declaration had effect:

//$inspect Edit1.(FEnabled, FName, FCaption, Trim(FText))

All the formatting and tricks that can be done in the inspector, should be applicable in the $inspect template.

 

 

You can still expand the Edit1 to see the fields, although I'd like an "All" option and a scrollable list, and perhaps a highlight for the $inspect featured fields.

Likewise, for the watch - it could suggest the $inspect template by default instead of the full list, with a checkbox to include all fields if so desired.

Another possibility would be to declare the $inspect template at the type declaration, having every instance of that type show the filtered field list. 

[Attila Kovacs 629]

you could do that from an expert but accessing (copying) the memory from the applications thread is very slow and not always work (as expected)

[Lars Fosdal 1792]

True, which is another reason to support something like this in the debugger.

[Attila Kovacs 629]

I'm not sure this would change anything as it works the same way.

I have rather close debug windows and delete watches if I want step through the code, otherwise it's really slow.

 

Edited February 14, 2022 by Attila Kovacs

[Lars Fosdal 1792]

@Attila Kovacs I am not sure why you think this would be slower than the current inspection view?

Massaging the data for display is not that time consuming, considering you already are in a breakpoint situation - or are you thinking about applying it for a logging breakpoint?

[Attila Kovacs 629]

Ah that, I see, you're right, no prob at all.

[Stefan Glienke 2002]

Nice idea - however I dislike using some special kind of comment format for that including the string for some kind of parsing.

 

As so often .NET solves this pretty nicely.

 

I would even claim this could be already be done by a third party and requires no work from Embarcadero - no claims on performance.

The debugger afaik is able to read RTTI from an inspected object and thus the attribute. It can then execute the proxy code which generates the output for the debugger. ToolsAPI has interfaces for that.

[SwiftExpat 65]

On 2/14/2022 at 7:37 AM, Lars Fosdal said:

Trim(FText)

What is the reason for trimming the text, debugging I would usually want to see something like '__'+FText+'__' to make sure I capture the spaces.

 

I agree with filtering, I am currently doing that with TMS FNC object inspector, only at runtime not as a debug visualizer.

[Lars Fosdal 1792]

5 hours ago, SwiftExpat said:

What is the reason for trimming the text, debugging I would usually want to see something like '__'+FText+'__' to make sure I capture the spaces.

 

I agree with filtering, I am currently doing that with TMS FNC object inspector, only at runtime not as a debug visualizer.

It was just an example of basic functions that could be applied.  That said, some of the ancient APIs we rely on, are fixed length strings that are space padded.

The idea was that whatever you can do in the evaluator today, should be possible to apply to the inspect format string.  

[Lars Fosdal 1792]

15 hours ago, Stefan Glienke said:

I dislike using some special kind of comment format for that including the string for some kind of parsing.

It is not ideal, I agree - but it is easy to introduce. If it fails, it fails - and you fix the comment, and it works.
I like the .NET approach too, but it does add a bit of "ceremony" - but it definitively makes sense for frequently used complex classes.

[0x8000FFFF 22]

17 hours ago, Stefan Glienke said:

Nice idea - however I dislike using some special kind of comment format for that including the string for some kind of parsing.

 

As so often .NET solves this pretty nicely.

 

I would even claim this could be already be done by a third party and requires no work from Embarcadero - no claims on performance.

The debugger afaik is able to read RTTI from an inspected object and thus the attribute. It can then execute the proxy code which generates the output for the debugger. ToolsAPI has interfaces for that.

To add - DebuggerDisplayAttribute

[Lars Fosdal 1792]

Instead of the inline "magic" comment, another option would be to have the definitions in a "hive" - be it flat file, database, registry or whatever.