setting : add restore to user state

[jacky]

I think a little addition to setting could be welcome. Right now it supports "0" or "1" of course, but also "r" to restore to previous state. There should also be an option "u" for restore to user setting.

Here's an example where it might be required : Imagine a script that needs to hide folders during its execution, then needs to restore that setting to user value before it makes a selection of items and ends the whole stack execution (end 1;) It's important to restore the user setting because otherwise the possible hiding or showing of folders would have the selection lost !

But, if this script was called by another script, which may have changed this setting as well before, then doing a setting "r" might not restore to the user value, and so our script has no way to ensure selection isn't lost, because it can't restore to user value, only previous in stack.

[admin]

Even with end 1; the settings are correctly auto-restored on each stack level. Please give an example where it does not work as it should.

[jacky]

Even with end 1; the settings are correctly auto-restored on each stack level. Please give an example where it does not work as it should.

I'm not saying it doesn't work as it should, but imagine smthg like this

Code: Select all

  setting "HideFoldersInList", 1;
  sel 3,1;
  end 1;

Well, if you were not hiding folders in List, they'll be back after the "end" of course, but also the selection will be gone, which is why it's a good idea to put a setting "HideFoldersInList", r; before making the selection. Only, when it doesn't restore to user value but what was set before this script started, which may have been something from another script, then there's no way to do it, and to make sure selection will not be lost.

Another case would be when the script calls a command to save settings, as the settings saved aren't the user settings but whatever is currently in use. So again in such case it's good to restore before hand, only if that can't be done because settings were previously changed in a script higher on stack, well, we're screwed!