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

[Martin_fr]

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)

Sorry, have to ask for clarification (again)....

Is that solved by the "[ + ] expand" of watches?
(In hints, it is already multi-line, and in the "Inspect pane" too / the column align is todo)

The whole idea of the watches window is to have a condensed view, allowing to see many watches in a list.

The idea of the [ + ] toggle is to give the expanded view, when/if needed.
If the height of each line would be extended, for showing watches multi-line (while not expanded) then we wouldn't need the

• ?

What am I missing?

---
Also check my summary, did I miss any other point?

[440bx]

Sorry, have to ask for clarification (again)....

Please don't be... I'm the one who has failed to provide clarification.

The best way for me "clarify" would be to a screenshot showing the way it currently displays it compared to a screenshot of what I'd like.  That would be a real clarification but, creating the screenshot of what I'd like takes a little bit of work and I'm currently in the middle of porting some C code and I want to finish that because that code's behavior is currently fresh in my mind.

Bottom line: I owe you a clarification.  It will be the first thing I'll do after that port of C code.

Sorry for keeping you waiting...

[Martin_fr]

Sorry for keeping you waiting...

Please, neither should you be.

Besides, this is a long term project. Some stuff may fit in soon, other later.

[440bx]

Please, neither should you be.

Thank you!.

[han]

The debugger works very well. I have only a few minor remarks for the format of arrays:

Editor hint.
a) Why is a horizontal scroll bar displayed?
b) The information len=3 is correct but it is a three dimensional array.

Evaluate/Modify window   Perfect useful display of the array information by entering img[1,4..9,6..9]
c) Why not a horizontal scrollbar?


Watches window
d) Adding img[1,4..9,6..9] to the Watches didn't work.
e) Would personally prefer the Evaluate/Modify behavior/format to be copied to the Watches. The Watches display of arrays look smart but to me less useful then the displayed format in Evaluate/Modify window.

Outside this topic, but I would like have the possibility to enter in the Evaluate/Modify and Watches expressions like sin(x), pi, ord('A').

Han

[han]

One more remark. Two dimensional arrays defined as [0..height,0..width] are in Evaluate/Modify displayed as tables. As soon the array is three dimensional it is no longer displayed as a table. Assume the array is defined as [0..2,0..height,0..width] I would expect three tables of width x height. See screenshot.

[Martin_fr]

Editor hint.
a) Why is a horizontal scroll bar displayed?

Very good question. Ignoring that the overall presentation could/should be improved, currently IIRC the debugger prints this as ONE single line.
The IDE hint (not currently controlled by the debugger) should do the wrapping (or keep all in one line).

In any case, having wrapping and scrolling => wrong. (bug report please, if you can)


EDIT: scrap that.
The debugger is wrapping, for each sub-array.
The hint does not have word-wrap, so it adds a scrollbar.

This will eventually have to be changed, but at the moment there are 2 independent stages.
1) the debugger create a string (with line breaks). The debugger is not aware of where or how this string will be printed (it only gets told, that the target supports multi-line / but has no idea how long a line can be)
2) The hint prints that string. (same in the eval/mod window)

b) The information len=3 is correct but it is a three dimensional array.

Ok....

However, in general each nested array can have a different length.
So the first step would be to have a length in front of each nested (and sub nested) array

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

1. Len: 3 (Len: 10 (1,2o3...), Len:15 (.....

As an optimization, if all nested arrays have the same length, that could be pulled up to the top level.
That however only works if the length of the top level is within certain limits.
As you can see, if there are to many elements in an array, not all of them are fetched => and then any non-fetched could still have a different length.
(there are settings in Tools > options > debugger backend -> how many entries to fetch)

For static arrays, it should always be detectable.

Evaluate/Modify window   Perfect useful display of the array information by entering img[1,4..9,6..9]
c) Why not a horizontal scrollbar?

Would a word-wrap checkbox be enough?

There are cases where people may want wordwrap. "array [1..99] of string;" (very long strings)

Watches window
d) Adding img[1,4..9,6..9] to the Watches didn't work.

Please create a bug report for that. Thanks.

As a workaround: x[1][4..9][6..9]

--- EDIT ---> Hopefully fixed in 3.99 (decision on merging to 3.4 still outstanding)

e) Would personally prefer the Evaluate/Modify behavior/format to be copied to the Watches. The Watches display of arrays look smart but to me less useful then the displayed format in Evaluate/Modify window.

The watches Window has an "inspect pane" (but only one watch at a time".

The idea for the watches window is to default to single line representation, unless the user expands that.
Would I be right to assume, you want the "multiline text" from eval/mod shown in watches, if you press the [ + ]?
If so, how many lines of text? (I mean an array [1..9999] would display a very large field, and all other watches below, would be hard to reach.

Keep in mind, that this is not only a display change.
The current expansion creates a new watch for each (displayed) entry of the array.
- In case of nested data, the new watch goes one level deeper than its parent.
- You can drag/drop individual entries from that list to become a new watch at top level. So if you are interested in "yourarray[7]" you drop that outside the expanded list, and it stays visible when you collapse the list.

Outside this topic, but I would like have the possibility to enter in the Evaluate/Modify and Watches expressions like sin(x), pi, ord('A').

An intrinsic https://wiki.freepascal.org/FpDebug-Watches-Intrinsic-Functions for ord seems plausible (even though you can do "byte('A')" already.
sin/pi => maybe... (mind as intrinsics they need the prefix, or if you switch that off, then they hide the real functions (if your rtl has debug info)

You can add a feature request to the bug tracker.

I added 2 of your points to the list. word-wrap awaits feedback. The rest is for the bug tracker, please.  (if word wrap is ok, you may also report that as feature request)

[Martin_fr]

One more remark. Two dimensional arrays defined as [0..height,0..width] are in Evaluate/Modify displayed as tables. As soon the array is three dimensional it is no longer displayed as a table. Assume the array is defined as [0..2,0..height,0..width] I would expect three tables of width x height. See screenshot.

And if the array is defined as [0..height,0..width, 0..1] ?
Then it would probably be better as it is now?

The idea of having several outer blocks, each as a table of its own => generally good.

But, how to know when to use it?

[Martin_fr]

From the image (array control-bar in watches)

What does this do

https://wiki.freepascal.org/IDE_Window:_Watch_list#Viewing.2FExpanding_Arrays  (may need a better description / feel free)

Expanded Arrays are shown paginated. The embedded toolbar lets you change between pages. It also allows to increase the page size.

The 2nd value is the size of a page. And it is not limited to multiple of 10, you can enter any number.

However, it will cut off at the end of the array => Except when your start point (first number in the control bar) is outside the array bounds.
E.g. if you know there is valid memory, then you can view values outside the give bounds.

[han]

    Evaluate/Modify window   Perfect useful display of the array information by entering img[1,4..9,6..9]
    c) Why not a horizontal scrollbar?

Would a word-wrap checkbox be enough?

There are cases where people may want wordwrap. "array [1..99] of string;" (very long strings)

Correction. The wordwrap is available for the evalute/modify window. So that is good, no more remarks.

For the watches window I noted the horizontal scrollbar is displayed if you make the value column wider and reduce the window  width. So it can be controlled with the width of the value column. So that is also good. Wrapping the watches window would make navigation more difficult. I would keep it as it is.

Blue arrow buttons. Personally I more a fan of controlling the watches by the expression. So like string[13...40] or array[0..1,3..5,3..5]. The new blue arrow buttons are not useful for me. Rather confusing.  The unfold buttons with "+" and "-" are good. The behavior of the evalute/modifiy window for arrays suits me better.

Note that the string st[13..200] is displayed shorter that is should be. A bug? See screenshot.

And if the array is defined as [0..height,0..width, 0..1] ?
Then it would probably be better as it is now?

Such a structure would make the program slow. The largest dimension is best placed as last in the array. So array[0..2,0..height,0..width] is op]"]>Blockedm for speed if width is the largest dimension.

[Zvoni]

getting back to the Displaying of records (that thing with [ + ]):
Are "linked lists" accounted for?

think (Pseudocode)

Code: Pascal  [Select][+][-]

1. TMyRecord = Record
2.     SomeInt: Integer;
3.     NextRec:TMyRecord; //Or Pointer to MyRecord, whatever. You get the drift
4. End;

Beware, you could get into a deeply nested structure, depending how those values are retrieved, and/or if you cut off at the current element
Nevermind a cyclic Reference (4th element pointing back to the first one --> endless loop)

OTOH, what about?

Code: Pascal  [Select][+][-]

1. TMyRecord = Record
2.     SomeInt: Integer;
3.     NextRec:TMyOtherRecord;
4. End;

Would there be a [ + ] for "NextRec"?

[Martin_fr]

    Evaluate/Modify window   Perfect useful display of the array information by entering img[1,4..9,6..9]
    c) Why not a horizontal scrollbar?

Would a word-wrap checkbox be enough?

There are cases where people may want wordwrap. "array [1..99] of string;" (very long strings)

Correction. The wordwrap is available for the evalute/modify window. So that is good, no more remarks.

I meant an option to switch the word wrap off, and instead display the eval/mod window with a horizontal scrollbar.  If you have long Lines, and compare each line to the one above/below (so word wrap would be in the way)

For the watches window I noted the horizontal scrollbar is displayed if you make the value column wider and reduce the window  width. So it can be controlled with the width of the value column. So that is also good. Wrapping the watches window would make navigation more difficult. I would keep it as it is.

Ok.

Btw, Column width should be remembered. But if you use Anchordocking that is broken, and you have to set them after restarting the IDE. Bug in Anchordocking. (iirc reported)

Blue arrow buttons. Personally I more a fan of controlling the watches by the expression. So like string[13...40] or array[0..1,3..5,3..5]. The new blue arrow buttons are not useful for me. Rather confusing.  The unfold buttons with "+" and "-" are good. The behavior of the evalute/modifiy window for arrays suits me better.

Both options exist. A lot of time arrays are watched that have large amount of entries. In that case pagination is a nice feature. So setting the first page, and page size have use. (The ability to go outside the range is a (imho nice) by-product.

But it could be hidden (maybe by option), if the array has less than a certain number of entries. (I don't think it ever makes sense to unfold several thousand rows)

Note that the string st[13..200] is displayed shorter that is should be. A bug? See screenshot.

[13..200] means starting at index 13, and going to index 200 (inclusive). So in that case 188 chars, starting at 13. I only have the graph, so counting isn't fun... But it seems to be around that number of chars?

If you need the count, both values can be expressions. E.g. if you have variables Start and Count, you can do MyArray[start..start+count-1]
(the .. has the lowest precedence, so expressions on both sides will be calculated first)

And if the array is defined as [0..height,0..width, 0..1] ?
Then it would probably be better as it is now?

Such a structure would make the program slow. The largest dimension is best placed as last in the array. So array[0..2,0..height,0..width] is op]"]>Blockedm for speed if width is the largest dimension.

But writing a debugger can't assume that the user always choses the most optimal path. Besides for some people readability (as dictated by their data) goes over performance.

Mind, I can see the usefulness of tweaking display as you described. Just not by dictating one single layout. So some good way of control would be needed.


In the image the expanded table "not following the expression" => Any use of coma-separated index (at least combined with ..) is broken (bug). Their is a fix in 45a6759c3d633b346edc21a04539441bd320b7b0 in the git main branch. (not yet in any release, also not yet merged to fixes).

This affects the watches and local window, whenever the [ + ] button is used. Workaround: img[0..1][0..2][0..2]

[Martin_fr]

getting back to the Displaying of records (that thing with [ + ]):
Are "linked lists" accounted for?

think (Pseudocode)

Code: Pascal  [Select][+][-]

1. TMyRecord = Record
2.     SomeInt: Integer;
3.     NextRec:TMyRecord; //Or Pointer to MyRecord, whatever. You get the drift
4. End;

Beware, you could get into a deeply nested structure, depending how those values are retrieved, and/or if you cut off at the current element
Nevermind a cyclic Reference (4th element pointing back to the first one --> endless loop)

OTOH, what about?

Code: Pascal  [Select][+][-]

1. TMyRecord = Record
2.     SomeInt: Integer;
3.     NextRec:TMyOtherRecord;
4. End;

Would there be a [ + ] for "NextRec"?

The debugger only fetches to a certain depth (for any type). I have to lookup the exact depth. I have to check if it will abort cycles before that depth (I think at least in some cases it will). But even if not, to do the limit of depth, there is not going to be an endless loop in the debugger.

Yet, you can browse the nested list (or any other) to infinite depth. (NextRec has a [ + ], and then the next one has another...)

- If you haven't unfolded, the top level may show a depth N.
- If you unfold, each entry in the unfolded list will show a depth N from the top of the entry itself (so N+1 from the top).

That means as you unfold more depth becomes visible.

There currently is *not* a way to say: display the first 100 entries of the linked list. => I have ideas how to do that.

Probably an intrinsic.  ":flaten(MyFirstElementInList, 'NameOfFieldToPointToNextEntry')"
(of course with recursion safeguards....)
"flaten" because it could also be used for certain trees.


Currently you will have to click open [ + ] a hundred times...

[Zvoni]

The debugger only fetches to a certain depth (for any type). I have to lookup the exact depth. I have to check if it will abort cycles before that depth (I think at least in some cases it will). But even if not, to do the limit of depth, there is not going to be an endless loop in the debugger.

Yet, you can browse the nested list (or any other) to infinite depth. (NextRec has a [ + ], and then the next one has another...)

- If you haven't unfolded, the top level may show a depth N.
- If you unfold, each entry in the unfolded list will show a depth N from the top of the entry itself (so N+1 from the top).

That means as you unfold more depth becomes visible.

There currently is *not* a way to say: display the first 100 entries of the linked list. => I have ideas how to do that.

Probably an intrinsic.  ":flaten(MyFirstElementInList, 'NameOfFieldToPointToNextEntry')"
(of course with recursion safeguards....)
"flaten" because it could also be used for certain trees.

That's what i meant.
I have run into something like that in Excel-VBA (where the Watches-Window also has those [ + ] for nested stuff), and depending on the "size" for that nested stuff, theoretically you could run into an "Out-of-Memory"-Scenario.
It also depends, if you "fetch" the data "on demand" (User actually clicks on [ + ] to expand), or if you are "preloading" it

[Martin_fr]

That's what i meant.
I have run into something like that in Excel-VBA (where the Watches-Window also has those [ + ] for nested stuff), and depending on the "size" for that nested stuff, theoretically you could run into an "Out-of-Memory"-Scenario.
It also depends, if you "fetch" the data "on demand" (User actually clicks on [ + ] to expand), or if you are "preloading" it

Only a small depth is pre-loaded (and hence any recursion stops, if not otherwise halted). Ever arrays and strings have configurable limits (it global debugger backend opts).

And that is one of the reasons why the expand for arrays, use pagination => only the needed page will be fetched at the next higher detail level. (there is a cache then for a few pages, if you go forth and back)


And the [ + ] goes on demand.

Mind the [ + ] actually creates entirely new watches (but re-using some of the known data). You can drag and drop a watch from the expanded sub-tree into the main list. And then it is a stand-alone watch.
So instead of typing Foo.Bar, you expand Foo, and then drag/drop Bar to the top level list.

Btw pre-load. Watches are evaluated, even if the window is closed. This is triggered by the history window. (which you can switch off, but in the options, only in the window (power button), and which returns back to on, after IDE restart). But usually that does not cause any issue (unless you are on a laptop and closed the watches to save battery)