I like the "Current" because that is what applies to the expression being watched. Usually, the other "stuff" isn't of interest (at least not immediate interest.)
But, "current" can only be selected once the data has been evaluated. Click "add new" and the IDE has no idea what your expression will return. Then it defaults to "all".... That is the main reason for "all".
Also if you watch a structure, then fields inside can have numbers, enums,..... => and then those others can be of interest.
And then you can multi-select (hold shift and click more than one tab). So you can change enums and bool in one go. (Ok, that is not important, but doesn't harm)
I don't think that the "Default" radio items are necessary. I think that the default option should simply be selected, e.g, in the case of "Default (Deref)", I'd get rid of the "Default (Deref)" altogether and simply have the default state selected "Off"/"On"/"Only" (whichever applies.) Aside from getting rid of clutter, it shows what the default option is. Currently, it is unclear whether Default (Deref) means "Off", "On" or "Only".
This actually depends on the option.
Default for "signed" is important. Because it isn't just signed or unsigned. The meaning of default changes, depending on the type of the data. ("Step into" and "i" may no longer be qword but int64 instead).
If the user explicitly set it to "unsigned" then the int64 will be converted.
If it would be set to unsigned, due to the global default, then once it is set, it is set => same checkbox. No difference to having been set by user.
Mind, that I have the IDE of allowing different defaults, depending on the typename. So if the debugger says this is TMyNumber then that could changed the meaning of "default" to something different than it has for integer.
And that will get very complicated, if the default simple gets copied onto the current settings.
The same problem applies in the evaluate window. Here the expression is changed often. If the global setting were copied, then they must get copied each time the expression changes. But that would mean the user couldn't select a value that anymore and have it stick.
I do agree that for some settings (such as "deref") the "default" is irritating at first (especially because few will actually have there own default, and fewer several defaults).
One way would be to only show it (for those kind of options), if the default is something that can change.
Off course in that case, if you add the config for this, then all existing watches will be set explicitly to "not default" (but that may be very very minor).
---
About default not indicating what it is....
As I said, for signed it can't actually do that (or only if it has evaluated data, and then only for the current data, and that may then be misleading, because with the next "step into" the meaning of default can change).
The number-base had the same issue, but no longer has it. Originally pointers used that too, and pointers defaulted to hex, other numbers to decimal.
But, then as I said, the plan is, that the user can specify different defaults for different types (by typename). And then all "defaults" potentially don't know what they are.
But even now, where the user can only set one global default => The user can change that. And all watches an "default" will follow.
---
Though maybe there only needs to be one default for "base and sign". If the user selects a base they also must decide the sign. (and other future properties, such as lead zeros)
On the other hand (to make matters worse), for the "signed-ness" of numbers: If Default means to follow the global settings, and if the global settings are either "signed" or "unsigned", then how to force it bace to automatic.
Also in the global options, this should probably read "Automatic" rather than "Default".
However in the Project options, it is "default", since if the project options leave it on "default" then it follows the IDE global options.
https://en.wikipedia.org/wiki/The_Sorcerer%27s_Apprentice "The spirits that I summoned"
On that note and, I could be wrong but, it seems to me that as far as "Address format" the default isn't "Typed" as the label suggest. Playing with the thing left me with the impression that the default is "Address" not "Typed address". Therefore if the label "Default (Typed)" was not there, there could not be any source of errors or user confusion.
Ah, ok that needs to be improved. The "(Typed)" means "(Typed-ness of the address)" which can then be set to any of the options. (Like the "Default(Sign)" for numbers). It's the Category for which "default" is selected. Not the meaning of default.
At this stage, my suggestion is: get rid of the "Default" labels, I find they muddy the waters instead of making things clearer.
They need at least to be different.
I thought about a checkbox at the start of each line. If it is not set, then no settings have been made.
(Like in the color editor in the options. The checkbox in front of "foreground" needs to be set, for the color to be chosen)
It could be set automatically as soon as a radio is picked. And if it is unchecked then all radios are cleared.
It be the same amount of clicks to do anything. Only the checkbox works reverse.
- unchecked = default
- checked = specific value selected by radio
----
Then I wonder, if it makes sense to introduce each group with a label.
- Base
- Sign
- Show Char
- Enum ?
....
But many are so obvious....
-----
Also something like
[O] Default [O] Address [O] Typed Address
could be a checkbox
[X] Show address with typecast
And, if a default (aka, follow global options) is needed
[X] Override Global [X] Show address with typecast
I'd like to have the "override global" to be a single column, with ideally no text.... But there is no way to make that self explaining. (It would need some header, and some indicator, that it is a special column...)
Improved naming => always welcome.
the second line (below Address format) is about the _value_ at the address and that's not clear.
"numeric representation" may be a better word
And really, its just because people can store any data in "Items.Object" and stuff like that.
Yes, users can typecast. But not if they look at entries from the history list (currently they can't change the display format for that either, but that should eventually work)
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?
There... my $0.02 hopefully, there is something useful in there for you.
Any feedback is always useful. I only have one head, only one mindset. That is a limiting factor ;) (really whatever evolution has thought about that, probably evolution didn't ask for feedback ;) )
As far as the non-current stuff... I'd be inclined to put that in a different window altogether where global defaults are selected. IOW, I wouldn't have any options that are not applicable to whatever expression is being watched, e.g, if what's watched isn't a boolean variable then no "boolean" option anywhere in the window.
As, explained
Add new watch => no info on the result type yet
In the case of selecting formatting for record fields then, I would expect the user to double click on the specific record field and select whatever is available from the options that apply to the field's type.
Once it is expanded, then yes that is (will eventually be) an option.
In the Evaluate/Modify window it is not.
And also, the idea is, to have a toggle between "most outer value" and "values that are nested" => the structure "only address" currently makes almost no sense. But if you watch an array of TButton, then you may want the address of each button only. That allows you to see, if 2 entries refer to the same object.
So that may be limited to the global options....
As previously mentioned, the defaults for built-in types should be selected in a global settings window... something along the lines of... Tools->Options->Debugger->Display Format (but without the Default Labels)
and instead of the default labels, on that window, I'd have the "number", "enum", "boolean", etc arranged vertically in the space currently used by the "Default" labels.
They are already there. (yes the default labels, need to be replaced there.
(See also above, and reference to the same settings in the project options)
Recent
