Add-a-Button-to-Adjust-Strategy-Parameters

Oh, you want to do it the other way around. Good luck with that one!

QUOTE:
the other way around

Well..., yes... I am coder. The code is the boss...

QUOTE:
- or -
adjust parameter values with a compile, the same way as these parameters "appear" magically after a first compile.

Why doesn't it work that way in the first place? I thought the current misbehavior was a bug. Isn't this how WL6 does it?

The fact that the default parameter values get out-of-sync with the defaults in the code has confused me. This out-of-sync default behavior is not intuitive.

I find this whole topic confusing. What exactly do you want to change?

It sounds like you want the code to change to adopt to the values set in the parameter sliders. On each compile? On each save?

The idea is this. You start with some code.

CODE:
using WealthLab.Backtest;
using System;
using WealthLab.Core;
using WealthLab.Data;
using WealthLab.Indicators;
using System.Collections.Generic;

namespace WealthScript10 
{
    public class MyParams : UserStrategyBase
    {
      public MyParams()
      {
         AddParameter("Period", ParameterType.Int32, 10, 5, 20); 
      }

        public override void Initialize(BarHistory bars)
        {
         StartIndex = Parameters[0].AsInt;
         _sma = SMA.Series(bars.Close, StartIndex);
         PlotIndicator(_sma); 
        }

        public override void Execute(BarHistory bars, int idx)
        {
        }
      SMA _sma;
    }
}

1. Run the script.
2. You decide that the the default value should be 15, so you change this statement in the code.
AddParameter("Period", ParameterType.Int32, 15, 5, 20);
3. When you run the code, it's still using 10 as the default and the button "Reset Values to Defaults" is disabled.

fwiw, if you save and open the script, the new value (15) will be the default.

> 3. When you run the code, it's still using 10

And this 3) is considered a bug by me and superticker.

After the code change (mentioned by cone above) and a new compile the WL Paramater should go to 15.
Just the same as if I close and reopen the strategy.

Amazing the different things that annoy people. But thanks for explaining!

In my mind it shouldn’t change the sliders because they trump the code. But everyone has their own perspective 🤷🏼‍♂️

I agree with Glitch that the slider values should trump the code.

However:
Assume the default values are shown in the sliders. The "Reset Values to Defaults" button is disabled.
In the code you change a parameter's default value AND save the code.
The values don't change in the sliders, as expected.
But, the "Reset Values to Defaults" button is still disabled. I would assume the button would be enabled because the parameters' default values no longer match the sliders.
Note, from a little testing, the optimizer picks up the new default(s).

So, perhaps when save is performed, the strategy code should be scanned for the parameter default values and compare them to the strategy slider values. Then the "Reset Values to Defaults" button is enabled/disabled accordingly.

As a workaround, if I want to reset the sliders to the new defaults, I just change one of the slider values, which in turn enables the "Reset Values to Defaults" button and press it. For me, that's good enough.

QUOTE:
I agree with Glitch that the slider values should trump the code.

That's fine for the short term. But in the long term, the code should be the deciding factor. The question remains, "How to handle this discrepancy so it doesn't look like a program bug to the user?" What should be the intuitive behavior?

I think the intuitive behavior should be kept simple. No one is going to expect some complex behavior--that's not intuitive.

The simplest behavior: Have the Save-code operation reset the sliders to what's in the code. Now, in addition, if you want to have a button that takes the slider values and sets them into the code (say before saving), that's icing on the cake (but not required). Such a button should say, "Save slider values to code defaults" so it's clear what's happening.

I disagree. I would be startled if saving the code changed my slider values that I might have spent considerable effort to set manually.

QUOTE:
I would be startled if saving the code changed my slider values ...

Well, perhaps there should be a dialog box that comes up when saving the code with several clear choice buttons if the code defaults don't match the slider values.

I think that would be too obtrusive.

QUOTE:
I think that would be too obtrusive.

I think leaving people with the impression there's a bug in the program is poor presentation.

There needs to be clarification as to what's going on. Moreover, there's no way to know which choice the user wants unless you ask him during the save. Often times I'll make slider changes (for experiment) that I don't want to keep after modifying the code. Other times, I may want to save the slider values. It all depends on the current workflow.

You can set a default choice on the dialog box for the most common choice. And there's no need for the dialog box if slider values and code defaults match (like when you're just playing with the code).

Perhaps two separate Save buttons should be offered so you have the clarification:
[Save slider values into the code]
[Save only the code w/o slider settings]

You can turn the current Save button into a drop-down menu with these two choices.

QUOTE:
Well, perhaps there should be a dialog box that comes up when saving the code with several clear choice buttons if the code defaults don't match the slider values.
...
Perhaps two separate Save buttons should be offered so you have the clarification:

Sure thing, the product is definitely missing another dialog box or dropdown with exquisite options 😉
http://www.usabilitycounts.com/2012/01/31/simplicity-google-apple-and-your-company/

Please lets remember: The whole post and ongoing discussion is about the rare situation where a developer changes the parameter defaults in code.

It is not about something that happens (or happens not) always by saving the strategy.

So my suggestion looks like this:

If the devloper changes parameter defaults in code then the sliders are adjusted with the next save/compile probably with a confirmation box coming up.

This whole thing should happen just once in a (long) while.

The code default(s) are already saved with the Strategy. But just because you changed the code default doesn't necessarily mean you want that value to be used for the window "now".

So what's wrong' with Paul's idea to deal with this rare situation.

Setup:
You change the default in code.

Solution
Adjust any slider, and click Reset Values to Defaults.

If anything needs to be changed, I'd vote just for enabling the [Reset Values to Defaults] button on Save (an event) when the default parameters don't match the sliders.

QUOTE:
I'd vote just for enabling the [Reset Values to Defaults] button

I agree...

QUOTE:
enabling the [Reset Values to Defaults] button

Let's say [Reset Sliders to Code Parameter Defaults] just to be clear. My real issue is clarity so the user doesn't think there's a bug in the program (because he expects something else). Initially, I was even having trouble making the connection between "Sliders" and "Defaults" because the terse language doesn't explain this connection--and it needs to.

What's unclear?

- A strategy uses the value on the Settings page slider, also shown in the Main Window's slider panel.
- The default value is used when the strategy is first opened or used in another tool (Exception for Preferred Values).

What's unclear is what on earth sliders have to do with "some defaults" in the preferences. Once you got it (after reading this thread), it's clear. But it wasn't clear what defaults the program was talking about when I read it. And if I can get confused, then the casual WL user would be confounded.

At least add a tooltip explaining what "defaults" are being affected. The program has many defaults and preferences.