Forum > Debugger

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

(1/22) > >>

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:

--- Quote from: 440bx on February 07, 2024, 10:56:21 pm ---Type of data: record
It would be really nice if the fields were shown vertically (one line per field).

--- End quote ---

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?


--- Quote ---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.)

--- End quote ---
Maybe an example? I don't quite follow.

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


--- Quote ---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.)

--- End quote ---
- 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:

--- Quote from: Martin_fr on February 07, 2024, 11:06:09 pm ---Using FpDebug there is a [ + ] icon, and they can be expanded.

--- End quote ---
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  [+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i < x.length; i++) { x[i].style.maxHeight='none'; x[i].style.height = Math.min(x[i].clientHeight+15,306)+'px'; x[i].style.resize = "vertical";}};} --- 1-8000.0108            - IMAGE_NT_HEADERS -  1-8000.0108     108  [4]                            Signature : 00004550    (PE00)  1-8000.010c               - IMAGE_FILE_HEADER -  1-8000.010c     10c  [2]                              Machine :      8664 1-8000.010c +                        IMAGE_FILE_MACHINE_AMD64  1-8000.010e     10e  [2]                   Number of sections :         6  1-8000.0110     110  [4]                      Time Date Stamp : 5acc.fbb2    (2018/04/10 18:00:18)  1-8000.0114     114  [4]              Pointer to symbol table :         0 1-8000.0118     118  [4]                    Number of symbols :         0  1-8000.011c     11c  [2]              Size of optional header :        f0    (240)  1-8000.011e     11e  [2]                      Characteristics :      2022 1-8000.011e +                     IMAGE_FILE_EXECUTABLE_IMAGE           2 1-8000.011e +                  IMAGE_FILE_LARGE_ADDRESS_AWARE          20 1-8000.011e +                                  IMAGE_FILE_DLL        2000   1-8000.0120               - IMAGE_OPTIONAL_HEADER -   1-8000.0120     120  [2]                                Magic :         20b 1-8000.0120 +                   IMAGE_NT_OPTIONAL_HDR64_MAGIC  1-8000.0122     122  [1]                 Linker Major Version :           e    (       14) 1-8000.0123     123  [1]                 Linker Minor Version :           d    (       13) 1-8000.0124     124  [4]                         Size of code :      1.1400    (   70,656) 1-8000.0128     128  [4]           Size of   initialized data :      5.6c00    (  355,328) 1-8000.012c     12c  [4]           Size of uninitialized data :           0  1-8000.0130     130  [4]                      Entry point rva :        8388    [Va: 1-8000.8388] [FO:   7788] [   .text] 1-8000.0134     134  [4]                   Base of code (rva) :        1000    [Va: 1-8000.1000] [FO:    400] [   .text]  1-8000.0138     138  [8]                           Image base : 1-8000.0000  1-8000.0140     140  [4]                    Section alignment :        1000    (    4,096) 1-8000.0144     144  [4]                       File alignment :         200    (      512) 1-8000.0148     148  [2]       Operating system major version :           6 1-8000.014a     14a  [2]       Operating system minor version :           0 1-8000.014c     14c  [2]                  Image major version :           0 1-8000.014e     14e  [2]                  Image minor version :           0 1-8000.0150     150  [2]              Subsystem major version :           6 1-8000.0152     152  [2]              Subsystem minor version :           0 1-8000.0154     154  [4]                  Win32 version value :           0 1-8000.0158     158  [4]                           Image size :      6.c000    (  442,368) 1-8000.015c     15c  [4]                         Headers size :         400    (    1,024)  1-8000.0160     160  [4]                             Checksum :           0  1-8000.0164     164  [2]                            Subsystem :           3 1-8000.0164 +                           SUBSYSTEM_WINDOWS_CUI  1-8000.0166     166  [2]                  DLL characteristics :         160 1-8000.0166 +                                 HIGH_ENTROPY_VA            20 1-8000.0166 +                                    DYNAMIC_BASE            40 1-8000.0166 +                                       NX_COMPAT           100   1-8000.0168     168  [8]                   Stack reserve size :     10.0000    (1,048,576) 1-8000.0170     170  [8]                   Stack  commit size :        1000    (    4,096) 1-8000.0178     178  [8]                   Heap  reserve size :     10.0000    (1,048,576) 1-8000.0180     180  [8]                   Heap   commit size :        1000    (    4,096)  1-8000.0188     188  [4]                         Loader flags :           0  1-8000.018c     18c  [4]             Number of rvas and sizes :          10    (       16) 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).

Navigation

[0] Message Index

[#] Next page

Go to full version