Poll: Watches and DisplayFormat => How do you think data should be displayed

[Martin_fr]

For each data type (integer, class, record, ...) the watches Window has some way to display it.

Some people will like very verbose, others rather condensed output. There may be many preferences. This poll is to help me understand what those preferences are. (It is not a vote).

What it is not about.

Anything that falls into the below categories, please do not add to this topic. Thanks.

1) Content, rather than Format:
  I know "properties" are not currently shown, I agree they should. But that is not about the DisplayFormat.
  I know "interface" shows empty. Not a format issue.

2) Stack, Threads, Evaluate, Inspect window.
  This is only about Watches and Locals (and maybe/probably eval in Editor-Hints)

3) Color or font-style
  Just text. E.g. "Foo=1" vs "Foo = 1" vs "Foo: 1"

4) Not about specific types
  TDateTime is  floating point and show as such => there needs to a better way. But in this topic, this would be how should all/any data of type float be shown.
  TPoint/TRect will be handled the same as any other "record"

  Individual display rules for such types are important => but not part of this topic

5) The ability of expanding/collapsing a value with the [ + ] / [ - ] icons

6) Customizable config (beyond the choice of DisplayFormat). A valid point, but not this topic.

7) Bugs
  If any data currently is displayed buggy => Bug tracker please.

8) Partly not: Shortcomings of gdb based debugging (or any debugging without FpDebug in the name). Those can be listed, but the main target is formatting when/if FpDebug is involved.

If you have questions or suggestions on any of those, please open a new thread.

What it is about.

Watches have a DisplayFormat ("type" in the watch properties).
Locals and Hints use the default DisplayFormat.

An Integer watch can be accordingly displayed as decimal, hex, bin, ...
For records classes, there is default vs structure.

The values are then (or can be) printed in different ways.

E.g. should numbers have in some format thousand seperators?
Should structures (or nested structures) have fieldnames, should it be colon or equal, ....


So if anyone has ideas of what the would prefer, the entry should include
- type of data: ordinal, floating-point, record, object, class, boolean, enum, set of, array, ....
- current output
- desired output

Exception to point (7) above: Maximum display length (before cut off) for strings. Or strings in (nested) structures. Or arrays, nested arrays.... Those may depend on DisplayFormat and if the data is stand alone, or in a structure or array.

Thanks for any feedback.

EDIT: Suggestions for the editor-hint or locals Windows => please mark accordingly. Default assumption is the Watches window.

Below is a summary of the suggestion - todo, not yet in 3.99 (To be updated occasionally)

https://forum.lazarus.freepascal.org/index.php/topic,66143.msg505542.html#msg505542 440bx
* For records/structures in multi-line print (e.g. in editor-hint):
  - One field per line Awaiting clarification
  - horizontal (table) align columns for labels and data.

https://forum.lazarus.freepascal.org/index.php/topic,66143.msg505546.html#msg505546 440bx
* When several numbers are printed vertical (array) then right align them (or align on the decimal dot).

https://forum.lazarus.freepascal.org/index.php/topic,66143.msg508582.html#msg508582 440bx
* "array of char" as string display. (including cut-of/deal-with trailing #0)

https://forum.lazarus.freepascal.org/index.php/topic,66143.msg508632.html#msg508632 Nicole
* Per watch switch for Date-time "watch visualizer" (print float as date)

https://forum.lazarus.freepascal.org/index.php/topic,66143.msg509012.html#msg509012 avra
* some form of quick-toggle between certain display formats
  (also by 440bx for data/mem-dump toggle)

https://forum.lazarus.freepascal.org/index.php/topic,66143.msg509474.html#msg509474 han
* "len" prefix for nested array
* :ord() intrinsic
* Eval/Mod-Win: disable word-wrap for table display

https://forum.lazarus.freepascal.org/index.php/topic,66143.msg509486.html#msg509486 han
* 3 (or higher) dim array: Display in blocks, so Y can be used for 2nd or 3rd dimension (allow decision which dimension make x/y)

https://forum.lazarus.freepascal.org/index.php/topic,66143.msg510643.html#msg510643 han
* Watches: Make array toolbar optional, if array-len is less than one page Added "AutoHide" and default for PageSize, can be controlled in DisplayFormat settings

https://forum.lazarus.freepascal.org/index.php/topic,66143.msg510651.html#msg510651 zvoni
* list display for nested list See https://forum.lazarus.freepascal.org/index.php/topic,67980.0.html

https://forum.lazarus.freepascal.org/index.php/topic,66143.msg511327.html#msg511327 440bx
* Option to display address short / without leading zeros

https://forum.lazarus.freepascal.org/index.php/topic,66143.msg511387.html#msg511387 440bx
* Multi-line text representation: Option to multi-line nested values (at higher indent)
  Also, nested Pointer should keep deref value as multiline (compare pane on images) https://forum.lazarus.freepascal.org/index.php/topic,66143.msg512401.html#msg512401

https://forum.lazarus.freepascal.org/index.php/topic,66143.msg512401.html#msg512401 440bx
* review repeat count

[440bx]

Type of data: record

Record fields in the watches window are shown horizontally.  That often forces the user to scroll horizontally to see more information (obscured fields/values that are on the right hand side)

It would be really nice if the fields were shown vertically (one line per field).  This would probably require scrolling vertically sometime but, it would probably be easier to scroll vertically than horizontally.

Another thing that would make inspecting the data a lot faster would be to have  the labels and the values justified in such a way that all the labels and the values are flush on the right hand side (like the output of my Pedump/Pebytes program.)

Another very desirable feature (at least to me) is to have all integer fields displayed in hex instead of decimal.   It would be wonderful if there was some way to make that happen (either on the fly or some global setting.)

Thank you for asking

[Martin_fr]

Type of data: record
It would be really nice if the fields were shown vertically (one line per field).

Using FpDebug there is a [ + ] icon, and they can be expanded.

There may be a question, if an option is needed to "auto expand", and if to only expand if the record (and similar class) has a minimum, or not more than a maximum number of fields.

EDIT: On 2nd thought: you mean if displaying in the editor hint?

Another thing that would make inspecting the data a lot faster would be to have  the labels and the values justified in such a way that all the labels and the values are flush on the right hand side (like the output of my Pedump/Pebytes program.)

Maybe an example? I don't quite follow.

EDIT: On 2nd thought: you mean if displaying in the editor hint?

Another very desirable feature (at least to me) is to have all integer fields displayed in hex instead of decimal.   It would be wonderful if there was some way to make that happen (either on the fly or some global setting.)

- As in a global setting to modify default display format?
- As in an ability to set (on each watch) the displayformat for fields in an array/structure?

EDIT: or display hex and decimal together (could make sense for values that are on their own line / maybe in the hint)

[440bx]

Using FpDebug there is a [ + ] icon, and they can be expanded.

I'm glad you mentioned that.  I was using an older version of Lazarus which didn't have that.   I probably have about a dozen versions of Lazarus... I often don't even know what version I'm using.  Anyway... I started a project I'm working on with Lazarus v3.0 stable and got the + and - signs

To make it easier to visualize what I'm talking about, I attached a screenshot.

In the screenshot, it would be very nice if the "DECODER_MODE" (4th variable from the top) could be shown in hex instead of decimal (that mode is the result of or-ing a bunch of masks and seeing it in hex would definitely be helpful.) I think it would be nice (not to mention useful to some programmers) to have all integer fields default to be shown in hex. I think it should be a global setting because, I'd find it tedious to have to set it individually for each field.  One possibility that would be nice is to display it in the "other format" (hex if decimal or, decimal if hex) if the mouse is hovered over the value (maybe in a tooltip ?)

The other thing that would be nice would be to "verticalize" the formatting of function/procedure types.  See the "FUNC_xxx" names towards the bottom of the screenshot.  Some of the prototypes require horizontal scrolling, it would be nice if there was a "+" sign to have the parameters and their type be one per line.  I have admit that, this is rarely an issue.  It just so happens that I'm working on something that uses callback prototypes but, it's not something I commonly need (unlike fields in hex... literally need that all the time.)


The thing about aligning as in Pedump/Pebytes... here is a quoted output from that program

Code: Text  [Select][+][-]

1.  1-8000.0108            - IMAGE_NT_HEADERS -
2.  
3.  1-8000.0108     108  [4]                            Signature : 00004550    (PE00)
4.  
5.  1-8000.010c               - IMAGE_FILE_HEADER -
6.  
7.  1-8000.010c     10c  [2]                              Machine :      8664
8.  1-8000.010c +                        IMAGE_FILE_MACHINE_AMD64
9.  
10.  1-8000.010e     10e  [2]                   Number of sections :         6
11.  
12.  1-8000.0110     110  [4]                      Time Date Stamp : 5acc.fbb2    (2018/04/10 18:00:18)
13.  
14.  1-8000.0114     114  [4]              Pointer to symbol table :         0
15.  1-8000.0118     118  [4]                    Number of symbols :         0
16.  
17.  1-8000.011c     11c  [2]              Size of optional header :        f0    (240)
18.  
19.  1-8000.011e     11e  [2]                      Characteristics :      2022
20.  1-8000.011e +                     IMAGE_FILE_EXECUTABLE_IMAGE           2
21.  1-8000.011e +                  IMAGE_FILE_LARGE_ADDRESS_AWARE          20
22.  1-8000.011e +                                  IMAGE_FILE_DLL        2000
23.  
24.  
25.  1-8000.0120               - IMAGE_OPTIONAL_HEADER -
26.  
27.  1-8000.0120     120  [2]                                Magic :         20b
28.  1-8000.0120 +                   IMAGE_NT_OPTIONAL_HDR64_MAGIC
29.  
30.  1-8000.0122     122  [1]                 Linker Major Version :           e    (       14)
31.  1-8000.0123     123  [1]                 Linker Minor Version :           d    (       13)
32.  1-8000.0124     124  [4]                         Size of code :      1.1400    (   70,656)
33.  1-8000.0128     128  [4]           Size of   initialized data :      5.6c00    (  355,328)
34.  1-8000.012c     12c  [4]           Size of uninitialized data :           0
35.  
36.  1-8000.0130     130  [4]                      Entry point rva :        8388    [Va: 1-8000.8388] [FO:   7788] [   .text]
37.  1-8000.0134     134  [4]                   Base of code (rva) :        1000    [Va: 1-8000.1000] [FO:    400] [   .text]
38.  
39.  1-8000.0138     138  [8]                           Image base : 1-8000.0000
40.  
41.  1-8000.0140     140  [4]                    Section alignment :        1000    (    4,096)
42.  1-8000.0144     144  [4]                       File alignment :         200    (      512)
43.  1-8000.0148     148  [2]       Operating system major version :           6
44.  1-8000.014a     14a  [2]       Operating system minor version :           0
45.  1-8000.014c     14c  [2]                  Image major version :           0
46.  1-8000.014e     14e  [2]                  Image minor version :           0
47.  1-8000.0150     150  [2]              Subsystem major version :           6
48.  1-8000.0152     152  [2]              Subsystem minor version :           0
49.  1-8000.0154     154  [4]                  Win32 version value :           0
50.  1-8000.0158     158  [4]                           Image size :      6.c000    (  442,368)
51.  1-8000.015c     15c  [4]                         Headers size :         400    (    1,024)
52.  
53.  1-8000.0160     160  [4]                             Checksum :           0
54.  
55.  1-8000.0164     164  [2]                            Subsystem :           3
56.  1-8000.0164 +                           SUBSYSTEM_WINDOWS_CUI
57.  
58.  1-8000.0166     166  [2]                  DLL characteristics :         160
59.  1-8000.0166 +                                 HIGH_ENTROPY_VA            20
60.  1-8000.0166 +                                    DYNAMIC_BASE            40
61.  1-8000.0166 +                                       NX_COMPAT           100
62.  
63.  
64.  1-8000.0168     168  [8]                   Stack reserve size :     10.0000    (1,048,576)
65.  1-8000.0170     170  [8]                   Stack  commit size :        1000    (    4,096)
66.  1-8000.0178     178  [8]                   Heap  reserve size :     10.0000    (1,048,576)
67.  1-8000.0180     180  [8]                   Heap   commit size :        1000    (    4,096)
68.  
69.  1-8000.0188     188  [4]                         Loader flags :           0
70.  
71.  1-8000.018c     18c  [4]             Number of rvas and sizes :          10    (       16)
72.  

Having numeric values right justified can really help visualize differences in magnitudes.  Of course, that's only applicable to numbers.  Closely related to that, numbers are usually much easier to read when they are displayed in a monospaced font (but it's a pain to have to output with multiple fonts, makes alignment more tedious, I'd consider that "nice to have" but, no biggie if the font is proportional.)

I don't think that an "auto expand" is necessary.  The little + and - do the trick just fine (at least IMO.)

It would be _great_ if the editor hint could be made - format-wise - closer (or very similar to) the way things are displayed in the watches window.  Currently the lack of alignment makes reading the information in the editor hint a bit cumbersome (screenshot attached as an example.)

[Martin_fr]

Still fuzzy on the alignment....

In the hint, I can see where to put it. Well, once values in a structure a one per line. Then each line would be "FieldName: >>> Value" where >>> aligns the value.
(Still tricky, since the debugger delivers the text, not font and/or painting / but that can be amended)

In the watches Window, I am not so sure, when, how, what. In case of an expanded array (or if 2 equal types are just below one another), then I could see it (e.g. in a expanded "array of TPoint" to align the X and Y. => tricky though, since each value is formatted on its own.
(and an expanded array, makes each element a value of it's own, that is needed to increase detail level, e.g pull in more nested arrays).
Interesting idea non the less.

I do understand the hex bit - though I disagree on "should always be hex". There are cases where decimal is needed. E.g. to see how many digits it has for an enduser. I currently don't have 10000 as hex in my head, and that is where 5 digits start. (e.g. debugging line number gutter of synedit).

[440bx]

From the thread https://forum.lazarus.freepascal.org/index.php/topic,66398.msg508570.html#msg508570

It would be nice if the characters in a null terminated array of characters were displayed without single quotes and without commas separating them.

For instance, it would be nice if the attached screenshot had no single quotes (except for possibly one at the beginning and another one at the end) and no commas.  That would save a lot of space and make the character string much more readable.

[Nicole]

Thank you so much for your work and this poll!

1)
Please let me have a checkbox "display in dateformat".

Often I have data in the format double, e.g. 45122.
May be the compiler does not guess, it is a date. There I want to have the option "display as date" and see e.g. "25.4.2024"

2)
Those not-shown properties and forbidden to talk about, sure, we all want them.
What about a sorting for the first?
If I let display all items of a component it is that verbose, that I give up to search for a certain value.
What about sorting the view by alphabet or let me key in a search value?

e.g. I want to see ibquery.sql.text => sort all post ibquery. by alphabet / or let me key in "text" anywhere.
Not sure, if this is possible at all.

[Martin_fr]

1)
Please let me have a checkbox "display in dateformat".

Often I have data in the format double, e.g. 45122.
May be the compiler does not guess, it is a date. There I want to have the option "display as date" and see e.g. "25.4.2024"

In progress https://forum.lazarus.freepascal.org/index.php/topic,66186.0.html
Currently you switch them on/off for a type-name (mind that "type foo=bar" does not create a new typename, but "type foo=TYPE bar" does. Per watch toggle is planed.
More discussions on this, please ask on the linked thread.

2)
Those not-shown properties and forbidden to talk about, sure, we all want them.

Not forbidden... Just not on this thread. This here is about how to display data that is available. Unfortunately properties need changes in the compiler in order to become available. (For more details ask in a new thread please, in case of interest)

What about a sorting for the first?
If I let display all items of a component it is that verbose, that I give up to search for a certain value.
What about sorting the view by alphabet or let me key in a search value?

Generally possible, and nice idea.

There are various places of sorting:
- In the one line display (when the watch is not expanded) => though if you have that many fields then the one line view wont help. sorted or not.
- In the multi-row expanded list

For that I am also thinking of adding a filter. Much like already existent in the "inspect window".

You can open the inspect window from the View>Debug-Windows menu, or the context menu of any watch.
For an object it will display each field on a row => and it has a filter to search for fields, or text in the data. (always searches both)
Once found, the row can be double clicked, and then added as watch.

[avra]

This here is about how to display data that is available.

While I expect to have a default representation of each data type, it would be nice to have a way for quick change of data representation without having to dig into some settings form each time. For example, numbers can be represented in decimal, hex, octal or binary form, and default could be decimal. It would be nice if I would be able to quickly change representation of a single variable (or even whole data type at once) with something like a simple SHIFT+CLICK which would simply loop through possible representations. That could be used for other data types as well (like single/datetime).

It sounds like a nice way to avoid visual overload.

[Martin_fr]

it would be nice to have a way for quick change of data representation without having to dig into some settings form each time. For example, numbers can be represented in decimal, hex, octal or binary form, and default could be decimal. It would be nice if I would be able to quickly change representation of a single variable (or even whole data type at once) with something like a simple SHIFT+CLICK which would simply loop through possible representations.

There is certainly demand for it https://forum.lazarus.freepascal.org/index.php/topic,66398.msg508697.html#msg508697 (about toggling mem-dump on/off).

Maybe it can toggle between different user settings... E.g.
- current/previous setting => though that would only cover 2 numeric formats.
- global defaults for settings will come, then it could be: toggle specific watch settings vs defaults.

Mind there is also the extend of what should get toggled...
- the "display format" (aka style).
  - including/excluding the mem-dump (because while advertised as display-format, it is different data (e.g. for non-packed records, it includes gaps)
- the value-formatter https://forum.lazarus.freepascal.org/index.php/topic,66186.0.html
- the value-converter (e.g. how variants are displayed) / again this is actually choosing to watch different data
- settings like repeat count / again this is actually choosing to watch different data

Yes, I am over-complicating it, but just to get opinions on which to base a decision.

But I like the idea, not to have it in the context menu....

Also have a look at the toolbar in the evaluate dlg for 3.99. => Similar toolbar, but only show the settings relevant to the top-level value.

top-level value => because for a structure you could chose "only values", "with field names", "full". So that (and if/how to show the address) are the structure values that could be in a toolbutton dropdown.

Well, then again, for a structure you can change decimal/hex/bin too => it affects the display of numeric fields inside the structure...

And then because decimal/hex/bin can be chosen for most watches (even if there top-lever property affects something else), those formats could have direct hotkeys, one for each format?
Or their own drop-down, for mouse users (or context menu?)

And just before the question arises: yes, whatever is chosen, it should/will work on multi-selection.

[han]

Thanks all for the hard work on the debugger.

For me the debugger has still a major problem. I'm writing and debugging math intensive astronomical programs. The watch displays the floats pretty rounded and is omitting for large values the decimals. This is highly confusing if you try to find small errors in the result.

For example I have a float for the Julian day called jd_mid with value  2458372.043715278.  The day is 2458372 and the day part is 0.043715278 which is about one hour. This is displayed by the debugger as 2458372.  The floating part is missing in the watch.  See screenshot.

I would like to have default the full precision like in GDB. If that is not possible this as an option.

Han

[han]

The same applies for the hints. This is also too much rounded. All important decimals are missing. See attached.

[Martin_fr]

The watch displays the floats pretty rounded and is omitting for large values the decimals. This is highly confusing if you try to find small errors in the result.

Have you tried Lazarus 3.2 ?

This should be fixed with now showing 9 (single) and 17(double) digits.
https://gitlab.com/freepascal.org/lazarus/lazarus/-/issues/40768

If you debug a 32bit app with "extended" then you need a 32bit IDE at the moment, since the 64bit IDE does not deal with that type.

[Martin_fr]

Lazarus 3.99 also has
- an option to show floats as "FloatToStrF(AResValue.AsFloat, ffExponent,  n, 0);". However fpc limits this to 15 digits.
- the ability to show this as human readable date (though if it is stored as "double" rather than "TDateTime" then it would be for every variable of type double.
   See https://forum.lazarus.freepascal.org/index.php/topic,66186.0.html / also for discussions on the "show as date" use that thread, please.

[han]

Great. With Lazarus 3.2 this all working as desired! My problem is fixed.