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

[440bx]

I'd add a heading along the lines of "value at address" and make the Signed/Unsigned options appear only when "Decimal" is selected (I don't think those option make sense for the other options.)

If I change "Address format" into "Number format for Address".
That together with above change to the "typed" option.

Better?

Not sure... I wasn't referring to the Address... I was referring to the format of the number found at Address.  Having a label that reads "for Address" gives (at least to me) the impression that what is is being modified is the format of Address instead of the format of the number located at that address.

As, explained
Add new watch => no info on the result type yet

Now I realize that I inadvertently focused on specifying characteristics of an already existing expression (I was debugging using my existing expressions.)  When it's a new expression, it's a different story.  Gotta keep that in mind.

I'll post more/other ideas when I have them

[Martin_fr]

I'd add a heading along the lines of "value at address" and make the Signed/Unsigned options appear only when "Decimal" is selected (I don't think those option make sense for the other options.)

If I change "Address format" into "Number format for Address".
That together with above change to the "typed" option.

Better?

Not sure... I wasn't referring to the Address... I was referring to the format of the number found at Address.  Having a label that reads "for Address" gives (at least to me) the impression that what is is being modified is the format of Address instead of the format of the number located at that address.

On the Structure tab, the settings in the red box, apply to the pointer itself.

That is, if you enable the green section, then an object (TObject, that has an internal pointer) will show as

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

1. $0000000021EC76F0: TAutoSizeBox(Control: nil; MinimumSize: (290, 0); ..........

Or just the address for "only".

Since we have an address column, this really is mainly for nested values.

Anyway in that case, this pointer can be shown in formats other than hex.

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

1.   L := TStringList.Create;
2.   L.AddObject('1', TObject(1));
3.   L.AddObject('2', TObject(2));
4.  

And the watch:

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

1. L.FList^[0..1].FObject

There isn't even an TObject to be shown from address $0001
But then maybe you added -739 as number. You might want to see it as such.

----------
there seems to be a bug: on/off are switched.

[Martin_fr]

So I done a mockup.

The checkbox at the start means: Value is user-specified.
- So if it is not set, then global defaults are used.
- If a radio is clicked, then it will be set automatically

Not sure:
- if it needs a label.
- if the label should be first (to the left of the box)

In the 2nd row, the checkboxes must be moved right, to be associated with the next dropdown.

And on that line, The may not need a label at all. (ok "Auto" would then need to read "Auto (Sign)" or "Sign as typed"
"Leading Zero" would be to have full 16 hex digits for a 64bit number.
"Extra" (better name) would allow a 2nd format for the numeric name (so it have dec, hex, bin, oct, char // mabye "dec, signed dec, unsinged dec,")

In the first row, the dropdown would currently have "oct", "char" (pointer would be removed, makes no sense, it is just unsigned hex)


Ignore the 2nd / old number block. Shouldn't be there.

For the other formats, it then needs to be decided what goes into dropdowns.
- If it is still to much (on the "all" page), as last resort "enum" and "float" could be on one line (with separator), then they would have dropdowns too.

If "current" or a single page is selected, dropdown (at least some/most) could expand into radios.

-----
Thoughts?

[Martin_fr]

The checkbox could move onto the divider line...
Of course, it still needs alignment... Just a mockup.

But it actually would free up the space of the "default" (well the first "default" in each section / but many only have one)

So with or without any of the other ideas, that seems to be useful.
And as far as intuitive / self explaining goes: "default" wasn't either. And a hint can be added.

--- EDIT:
There are a couple of options, when it's moved to the header.

1) As described, it means "Radios override global pre-set"
2) The other way: "Use global pre-set" (and then, if there is space, display the value of the pre-set in the header)

It could also be a radio-button in the header. Though that depends....


Currently (on the number example), there are still "default selectors" for "Signed-ness" (and for future "leading zeros").

Though, it is questionable if they do need there own "default/override". If the user overrides the base (e.g. selects binary), then it can be imposed that they should make a choice for those 2 too.

Pointer/Structure may then need more (or different) sub-divides. (To have good sets of what gets overridden together).

If however, the global default covers more than one radiogroup (base + sign + lead), then it would be weird, if it was a radio button (because it belongs to non-of the groups, but affects them all.

--- EDIT 2:
Alternative mockup image....

Radios:
I don't like the radios in the caption...

They could go to the front (but the current defaults would need to stay at the end, and that would be awkward too, imho)

Checkbox:
The natural default- as they relate to the settings below them - is that they enable those settings. Aka "Override the global settings, with the selection made on this form".

But, if the current global settings are shown in the header, then that may not be the expected behaviour any more.... Maybe a question of naming/wording.

[440bx]

Hi Martin,

You got me racking my brain thinking about how I would do it.  Not easy...

What I see as the main problem, which generates downstream problems is how to handle a click on the watches window "+" sign.

I see that as the main problem because when the user clicks the "+", the debugger has no information whatsoever about the type of the expression which means that it's not possible to show only the options that apply to a specific type because the type isn't known.

As a result of that, I'm thinking that the "expression" box should have a little "->" (arrow) that means "I'm done with the expression" (the arrow could be clicked using the mouse or "clicked" by simply pressing <enter>/<return>.)   At that point the debugger would know the type of the expression (presuming the expression is valid) and can show options that apply to that type of expression.  Limiting the options to only those that apply I think can simplify things.

The downside of that method is that using the "+" is now a 2-step process. First step: tell the debugger what the expression is.  Second step: select the appropriate formatting options for the type.

This method would also mean that if the user changes the type of the expression (by typecasting or changing an existing expression) then the user would be required to press return or click the little arrow to let the debugger know the expression has changed therefore the options may need to be changed to reflect the new expression type (if the change caused a change in type.)

What I'm really saying is that the problem I currently see is trying to have all the options for all types available at all times regardless of the expression's type.  I think that complicates organizing the options.

There are really only a few "root types" from which other types are derived. I think that if somehow the options are limited to those which apply to a given root type then there is a reasonable chance of ending with something nice and reasonably straightforward.

I am unable to see a good solution that gives all possible options regardless of the expression type.  Plus, in that case, there are options that don't make sense.  For instance, in v3.2 it is possible to select "Record/Structure" for a qword variable, ideally, I think that option (record/structure) shouldn't be there for that type (qword.)

The more I think about it, the more I believe that trying to make all options available regardless of type is what causes a lot of the problems in organizing the options.

My $0.02...

[Martin_fr]

As a result of that, I'm thinking that the "expression" box should have a little "->" (arrow) that means "I'm done with the expression" (the arrow could be clicked using the mouse or "clicked" by simply pressing <enter>/<return>.)   At that point the debugger would know the type of the expression (presuming the expression is valid) and can show options that apply to that type of expression.  Limiting the options to only those that apply I think can simplify things.

It's possible to add watches before pressing run, and then the arrow wouldn't work.

Also, if it is 2 click, in most cases the user knows what the type will be. So the user can then chose the correct tab for the displayformat.
Then it is just about condensing "all" to a selection of the most common of each type (so it wouldn't be "all" anymore.

I don't currently see how to completely avoid the "all" page. Other than removing it, and display one of the others as default (e.g. number), and the user has to switch, if they need "enum" or something else. (Auto detection could be added, but won't solve it because it is not always available)

Generally the idea of "evaluate while the properties are still open" is interesting. E.g. there could be a preview. The result and it's format depend on a lot of options now. So having a preview would be nice.
It may have to take the selected backend into account though. E.g. with FpDebug it is so fast, that if you make a change, it can just eval it on each keypress (and fpdebug is stable enough for that). If the IDE sends the (partial) expression to gdb on each keystroke, then it will end up having a queue, because the user types faster than gdb delivers. And on top, gdb may crash on the partial expression.
Of course, it could be on EditingDone. and then when changing other settings in the watch properties.
But that is a new topic.

Plus, in that case, there are options that don't make sense.  For instance, in v3.2 it is possible to select "Record/Structure" for a qword variable, ideally, I think that option (record/structure) shouldn't be there for that type (qword.)

Yes well, the old were quite limited... The new, well let's see.

First step I am doing now, is moving the default into the headers.
- A few radio less
- Better distinction between "inherit global" and "actual selection"
- fix, that they should be hidden in Tools > Options

Then I will likely select what remains on the "all" page. Or use dropdowns, but only on the "all" page, keeping radios on the individual pages.

[Martin_fr]

You were right. Removing (or as I ended up doing, just "moving") the "default" radios, does help. It makes it a lot less overwhelming.
In the images there are still some left, that I am still working on....
(also some labels/text need to be updated...)

It hasn't yet reduced the overall space, but its a step away from "way too much".

I am not yet sure, if the sections should be indented.
I also tried to align the first radio column, below the checkbox, but found it irritation (distinction between header and section becomes reduced).


I think, if a setting like "address: on/off/only" became a dropdown, and moved to the empty space in the line above => that would further help.
But will have to try and see.

(On the "structure" only tab, it would stay radiobuttons)

I also want to play with low-lighting the radios in groups that aren't activated (that default to global settings...)

[440bx]

I am not yet sure, if the sections should be indented.

I think some indent would be nice.  Personally, I'd try making the first radio button be flush with the left side of the label above it.  I think that's worth a try, see how it looks.

I think there is a noticeable improvement in the form of less clutter than the original.

Now, on a different note...

FPC, like C, considers pointers to be arrays.  Basically, a pointer to "something" is, potentially, an array of that "something".  I think that when a pointer to something (i.e, a typed pointer) is entered in the expression box _and_ the "repeat count" is greater than zero then "repeat count" elements should be shown (just like an array.)

In addition to being consistent with FPC's treatment of pointers as array, it would also be very convenient when there is a pointer to an array of pointers to something.  Refer to the attached screenshots.  In the screenshot, the variable (pointer) _GlobalData.gd_instructions_offsets is an array of pointers to a record structure. The watches windows only shows the first element in spite of the fact that the "repeat count" for that variable has been set to 5 (some reasonable number greater than zero) to see more elements they have to be manually added as shown in _GlobalData.gd_instructions_offsets[1] and _GlobalData.gd_instructions_offsets[2].  Ideally, once the repeat count has been set to a value greater than zero then a set of "bound selection values and arrows" would appear under that pointer name (now considered/seen as an array because the repeat count is greater than zero.) like those shown under the ii_instruction_prefixes (which happens to be a "real" array.)

Lastly and, this might just be a bug, notice how the formatting of the right hand side is different for the two screenshots even though it's displaying the same element type.  It looks like, for some reason, it considers them different.

Thank you for your patience and all the hard work you put into FpDebug.

I've forgotten to mention this and I don't want to forget it again.  Enabling FpDebug to correctly handle DebugBreak() was truly a make it or break it feature for me.  I have a lot of code with "IsDebuggerPresent()" that executes an "int 3" (which is still unwelcome) but, now I can replace the "int 3"s with DebugBreak() and have my code "debug ready" at any time. before that, I was forced to use GDB because all my debugging code would cause an exception.  Succinctly, FpDebug's honoring DebugBreak() is a life saver.  Also, now that I can use FpDebug, I find it much more pleasurable to use than GDB.  Thank you!

[Martin_fr]

FPC, like C, considers pointers to be arrays.  Basically, a pointer to "something" is, potentially, an array of that "something".  I think that when a pointer to something (i.e, a typed pointer) is entered in the expression box _and_ the "repeat count" is greater than zero then "repeat count" elements should be shown (just like an array.)

Agreed.... Though...

It may be different per backend....
And...

Currently the gdb backend can do a repeat count on "ptr[1]" => because then it has an index, and it knows what to increase.
(FpDebug does not (yet?))

And that is one way to interpret "repeat count".
But then it becomes ambiguous if "ptr[1]" itself is a typed pointer, and if typed pointer can also act on the repeat count.

So should "repeat count" act on the index (iirc last/deepest index)? Or on Pointers.  Index has the advantage, that  you can specify a start point.

If implemented as in gdb, then you would need a watch "Ptr[0]" to have "repeat count" working.

Mind that FpDebug can handle a typed pointer the same way like an array.
And that means, independent on which way the "repeat count" will act, you can do
 

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

1.   MyTypedPtr[5..14]

to get elements 5 to 14.

In addition to being consistent with FPC's treatment of pointers as array, it would also be very convenient when there is a pointer to an array of pointers to something.  Refer to the attached screenshots.  In the screenshot, the variable (pointer) _GlobalData.gd_instructions_offsets is an array of pointers to a record structure. The watches windows only shows the first element in spite of the fact that the "repeat count" for that variable has been set to 5 (some reasonable number greater than zero) to see more elements they have to be manually added as shown in _GlobalData.gd_instructions_offsets[1] and _GlobalData.gd_instructions_offsets[2].  Ideally, once the repeat count has been set to a value greater than zero then a set of "bound selection values and arrows" would appear under that pointer name (now considered/seen as an array because the repeat count is greater than zero.) like those shown under the ii_instruction_prefixes (which happens to be a "real" array.)

At the moment you can watch

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

1. _GlobalData.gd_instructions_offsets[0..5]

or

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

1. _GlobalData.gd_instructions_offsets[0..5]^

or

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

1. _GlobalData.gd_instructions_offsets[0..5]^.IILINSTRUCTION_OPCODE_LEN

The last one, if you only want to see the particular field of each record.

The ".." returns an array. And you can have more than one

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

1. _GlobalData.gd_instructions_offsets[0..5]^.IILINSTRUCTION_OPCODE[1..3]

if you want that subset of opcodes for each record.

And each of the index numbers can be an expression.

Lastly and, this might just be a bug, notice how the formatting of the right hand side is different for the two screenshots even though it's displaying the same element type.  It looks like, for some reason, it considers them different.

In this case its an unnecessary difference. The general issue was mentioned by someone else in this thread.

Currently the outermost element is formatted multi-line. All nested elements are single line.

That rule makes senes in case of "array of TPoint". The points do well if they are single lined. In that case better than if they were multiline.
Same for a "record a,b,c,d,e,f,g: TPoint"

But, if the nested structure is bigger, then its a case by case decision. It may be better to multi-line the inner struct too, and give it an appropriate indent.

In your case the outermost value is the pointer to pointer. Without having checked the code, from the display it appears to me, that a single pointer as outermost value is ignored. But a pointer to pointer is an outermost value that consumes the multiline, and displays the rest single line.
Yes, that could/should be seen as a bug.

I've forgotten to mention this and I don't want to forget it again.  Enabling FpDebug to correctly handle DebugBreak() was truly a make it or break it feature for me.  I have a lot of code with "IsDebuggerPresent()" that executes an "int 3" (which is still unwelcome) but, now I can replace the "int 3"s with DebugBreak() and have my code "debug ready" at any time. before that, I was forced to use GDB because all my debugging code would cause an exception.  Succinctly, FpDebug's honoring DebugBreak() is a life saver.  Also, now that I can use FpDebug, I find it much more pleasurable to use than GDB.  Thank you!

"int 3" or "int3" ? with or without space? They may act different.

If FpDebug with the feature enable handles only one (the one that compiles to $CC) then you can add a bug, as feature request to treat int3 and "int 3" both.

[Martin_fr]

Btw, on the first image in your previous post, the value in the inspect pane

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

1. PPInstruction($1234)^^: $2345^: (...)

The 2nd address of the intermediate pointer
- good feature
- acceptable / endurable
- bollocks
?

[440bx]

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

1.   MyTypedPtr[5..14]

to get elements 5 to 14.
<snip>
At the moment you can watch

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

1. _GlobalData.gd_instructions_offsets[0..5]

That's perfect!... that does the trick... that's as good as it can get.

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

1. _GlobalData.gd_instructions_offsets[0..5]^.IILINSTRUCTION_OPCODE_LEN

The last one, if you only want to see the particular field of each record.

That's great... I wouldn't even have dared ask for that one.

Yes, that could/should be seen as a bug.

is your being aware of the bug sufficient or would you like me to file a bug report for it ?

"int 3" or "int3" ? with or without space? They may act different.

I always use "int 3" (with the space) I haven't tried "int3" (until now)

If FpDebug with the feature enable handles only one (the one that compiles to $CC) then you can add a bug, as feature request to treat int3 and "int 3" both.

Yes, FpDebug treats them differently.  "int3" (one word) is fine but "int 3" (separately, i.e, CD 03) isn't, causes an access violation exception.  In the attachment, the first int3 goes fine, the second "int 3" doesn't.

I'll log a feature request to have "int 3" (with space) be treated the same as "int3" (without space.)  This is really getting better and better

ETA:

added the forgotten attachment

[440bx]

Btw, on the first image in your previous post, the value in the inspect pane

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

1. PPInstruction($1234)^^: $2345^: (...)

The 2nd address of the intermediate pointer
- good feature
- acceptable / endurable
- bollocks
?

It would be a good feature because that allows the user to verify the pointer is pointing into the expected block of memory and not some random block that happens to yield reasonable values.

[440bx]

The following has nothing to do with formatting per se but, I find it a very useful feature.  Refer to the screenshots, my editor has a little arrow (the one pointing left) on the right hand side of the "Search for:" box.  When that arrow is clicked, a number of common and useful regular expression identifiers appear. 

I find this extremely nice because in most cases I don't need a regular expression which means that when I need it, I rarely remember what character does what.  Having that little window (really a popup menu) with the most common options is a quite useful reminder when I need a regular expression.

In the case of FpDebug, I think that  having a button that doesn't even need to be clicked, just hovered upon, to present some "formatting trick" reminders would be useful.

For instance the trick about "@textvar[0]" to not have every character individually enclosed in single quotes is quite useful (not something I'm going to forget anytime soon either) and, the trick you just mentioned "Someptr[0..n]" where "n" is some value to create an array is great and I think should definitely be included in a little "reminder/cheat sheet" like that.

What I've realized is that, it's obvious you know formatting "tricks" that most users won't think about (like the ptr[0..5] for instance) that would be rather welcome in such a quick cheat sheet.

Of course, as previously mentioned, this isn't really about formatting, it's really a feature request: a little cheat sheet window with useful formatting tricks.  Also, initially it would only have a few, non-obvious, tricks which could be added on as new ones are thought of.  IOW, initially having just 3 or 4 tricks (or even less) in the little window would be fine.

[Martin_fr]

Yes, that could/should be seen as a bug.

is your being aware of the bug sufficient or would you like me to file a bug report for it ?

Added to the list of items in this thread (in my original opening post).

Also, you were the one who pointed out that nested values are "jumpled": https://forum.lazarus.freepascal.org/index.php/topic,66143.msg511387.html#msg511387
And internally, this falls in the same category.

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

1. PPInstruction($1234)^^: $2345^: (...)

The 2nd address of the intermediate pointer

It would be a good feature because that allows the user to verify the pointer is pointing into the expected block of memory and not some random block that happens to yield reasonable values.

Ok. In that case

1) the first pointer should have only one "^"

2) How to display in the main watches area when expanding?
I mean expand should probably still show the final deref value....

I have thought about allowing to expand pointers (even to non struct/array). E.g. expanding ^double would just show the double number (in the expanded row). A quick way to see it without address (if you don't want to change display format) in case of narrow columns.

But even then, if you had ^^^record => you would likely want to see the fields of the record.

And it's fine, but one minor detail.
- if you have a display format that shows the address(es) in the value column => then the top-level line shows all the addresses anyway => so all info is present.
- if your display format does exclude the address, and you use the "address column" => then that only shows the first deref address

So in the 2nd case, some addresses wont be shown...

In the case of FpDebug, I think that  having a button that doesn't even need to be clicked, just hovered upon, to present some "formatting trick" reminders would be useful.

Maybe...

Would depend on getting feedback on which "tricks" other people would find useful. And yes, a bit of a catch22: Many of those who would find them useful wont know them, and therefore can't give feedback.
But those who do, might have ideas what they think others would....

Also, it isn't as straight forward. Some of those rely on the backend. The ".." only exists in FpDebug (as do all of those https://wiki.freepascal.org/FpDebug-Watches-Intrinsic-Functions )

Which means, not only does the list have to know the backend... There is also the case that a user learns about ".." and then need to remote debug with gdb, and suddenly it stops working.

Then again, gdb has intrinsics too. But - within the IDE - that has not been tested (and may depend on gdb version).

For instance the trick about "@textvar[0]" to not have every character individually enclosed in single quotes is quite useful

While it might be worth advertising, I wouldn't name it a "trick".

It is normal pascal syntax. You simply watch an expression that returns a "pchar" => so you get to see a pchar. (which is displayed as string)


FpDebug does casting and converting. And hopefully the same way as FPC. (Gdb does not always do it the same way...)

That includes

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

1. type  TFoo = packed record a,b: byte; end;
2. var   foo: TFoo;
3.       bar: word;
4. begin
5.   foo.a := 1;  foo.b := 2;
6.   bar := word(Foo);

You can enter "word(Foo)" as watch.

Of course, as previously mentioned, this isn't really about formatting, it's really a feature request: a little cheat sheet window with useful formatting tricks.  Also, initially it would only have a few, non-obvious, tricks which could be added on as new ones are thought of.  IOW, initially having just 3 or 4 tricks (or even less) in the little window would be fine.

Maybe you can open a new topic on that (and moderate the topic), and see what others think.

In general, the debugger has tons of features that are probably seldom used.

* E.g. using the breakpoint hitcount.
If some code (testcase, that always runs the same behaviour) which is deeply nested in a loop, and fails after a certain amount (> 100) of calls, then just setting a breakpoint wont do it. You would have to single step more than a 100 times over the problematic line.
- set a non-breaking breakpoint, run the app, when it fails read the "pass count" of the breakpoint. Note that it passed (e.g.) 123 times.
- restart the code, this time with a breakpoint that has its hitcount set to 123 (so when it is about to be passed for the 123 time, it will stop).

* The history window
- if you debug focus sensitive code
- export the stack and watches of a crash, to be reviewed by a colleague.

* even watchpoints => I suspect are not as well known as they deserve

* pausing other threads (beta-ish)

* enable/disable breakpoints as other breakpoints are passed (with conditions on the other breakpoints)

But all that needs to go into another thread (if of interest)

Btw: Blaise Pascal Magazine has some Articles on the Debugger (starting most basic, IIRC in issue 105 with stepping)...
They offer a free subscription. I don't know if you can download the old one though (the German/Brasil subscription seem to allow that, by their description)

[Martin_fr]

Back to the Watch property dialog...
At this point more of an update than a query.
- For comparison, including the original....
- And ignore the obvious need for changing/fitting the captions.

IMHO, space wise its better .

Not yet sure on the "sub-dividers". E.g. between number-base and signed-ness. They are needed, but currently still to prevalent. Maybe dotted line.

The biggest problem now, is the uniformity of this big matrix. (Even though the checkboxes and lines help a little bit).

If you know that an option is in there, you can't quickly locate it. There are to few "visual anchors".
So I am going to play with a few dropdowns on the "all" pages.
- downside: if you are all new, you have to open them to know what is in
- upside: once you know what's available the can guide your eyes to the correct location (they provide easy to find visual differences in the grid)

Functionality-wise, each checkbox enables the section in front of which it is.
- Checkbox = off => radios are all deselected and defaults apply
- Checkbox = on => the settings of the radios apply

Clicking a radio will auto-set the checkbox

On the individual pages, I will try to print the defaults on top of the tab.
On the "all" page, there isn't enough space for that. (there may be a hint, when hovering)