Support for setting values to numeric and alphanumeric variables
GitMensch opened this issue · 25 comments
I will start working on setting variable values, and for me doesn't change opening a new issue or keep using this one. The only benefit of moving to a new one is a clean log.
Originally posted by @brunopacheco1 in #30 (comment)
This ticket is specific to setting fields in a "natural" way (so for example set a numeric-display variable as "5", not as "0000005", which is even more necessary for binary fields).
I'm going to change the title of this issue to reduce the current scope to only set numeric and alphanumeric values, as they are the only supported data types so far.
The other data types are going to be tackle by #59 , as they required new features not available yet in the GC.
@brunopacheco1 Do you have any good guess when you possibly will tackle this? (I know - there are so many interesting things here, and then also the life outside of coding free software).
I've been tempted to do this one, but as I started the #3 I thought to finish that one first.
As I suspected, we were missing a flag in the extension initialization. Now it looks there is "Set Value" support and it's minimally working fine. There is still some work to do, to check if this feature is working on GC 2.2 and it has to be disabled when it's a group variable (whenever there are children, otherwise I believe it should be enabled? @GitMensch is this assumption correct?).
Releasing a version with this feature is definitely a good thing, even when it's"minimal". What did you mean by that btw?
I meant, it was late and I was willing to go to sleep, but finally the extension was allowing the user to set values to a variable, and the first test worked, but the second not.
People often set group variables...
Good point, I'll pay attention on that as well.
Is setting to hex value possible, too?
If cob_set_field_str() allows it, then yes, otherwise there is a quite high chance of zero support, but the is a bit far from the current stage.
We will need to review the way the Variable Panel is built, to correct support the "Set Value" feature. As you can see in the print below, it is possible to edit the type of the variable.
The recommendation is to present the variable's value just right after the variable's name, and the variable type will be presented if you hover the variable name.
Anyway, I'll look for a way to disable this feature for given variables as it may be useful in different scenarios.
The recommendation is to present the variable's value just right after the variable's name, and the variable type will be presented if you hover the variable name.
I'd consider this totally a win (and this may be exactly what I've suggested before....). Please at least do this per the existing setting in the extension, see #48 (comment).
If the "extended" view would be primarily considered a gnucobol-debug-dev feature (and be deactivated by default) we could go with the vscode "standard" way of doing this and whoever uses the dev-setting may know to not change any of the "display-only 'variables'".
This is how the variable panel looks like after the latest changes when the "extended" variable mode is not enabled:
And this is how the variable panel looks when it is enabled:
In both cases the variables are editable, the difference is in the extended mode, only the attribute "value" is editable, the rest any edition is ignored and the previous value is presented back.
Please, let me know if it is okay. I kinda liked the not extended version, it looks cleaner now.
I am going to open the PR though.
Also: could we toggle it during a debug session? So far I've only found the option: change the setting, restart the session.
I just saw this comment. I had the same need during development. I would guess this is not possible as there are few actions available during a debug session and the are quite strict (Steps, Restart, Stop...), and in the variable panel, there is no available action.
I would have to investigate if it is possible to extend the debug action bar, but do you think this is a must?
@GitMensch I was playing around on setting values into group and fields when the functions cob_set_field_str and cob_set_field_str_buffered are not available, and I've got an interesting behavior. If I set the group value, the variables are updated, but if I set the fields, the group is not updated and the field is decoupled from the group update.
Do you have a suggestion on how to tackle this?
It did make sense and it is working as expected. Thanks a lot!
I still have to polish up the parsing of pretty strings into something suitable for display values though, but in general, the solution is quite good.
I still have to polish up the parsing of pretty strings into something suitable for display values though
Please elaborate. Do you talk about old GC versions where the cob_put_field_str() is not available? Otherwise it should be preferable for anything.
Yes, I meant when the functions for getting and setting field values are not available.
In that scenario, the extension supports only basic display values, and as the extension parses display values into prettified numbers, the extension should also support the opposite, parsing back the pretty formatted number into display values, to be set properly on GC runtime side.
I completely agree.
WS is not defined
debugging any program.
hello.txt
It looks like you have a variable that is called "WS" or it starts with "WS-" in your Watch Panel, but this variable doesn't exist.
I would guess you are not running the latest changes from master, but anyway, just by this log this isn't an issue.
@OlegKunitsyn @GitMensch Did you check the new feature? Is it working as expected?
I will close this issue, anyway, if any bug happens, we tackle it in a new one.