Size:
Color:
This is by (good) design. Despite that you think that you're not ready, your strategy is indeed ready to run because it has been compiled. Workaround: make a syntax error and leave it in to prevent successful compilation.
Or tell Wealth-Lab that it's still in testing by including a quazi-boolean Strategy parameter that aborts processing by default and activates the system's logic only when intentionally changed to the proper position.
Size:
Color:
Okay Thanks. I have seen what you are saying before, and will now adopt your suggestions.
Size:
Color:
QUOTE:
This is by (good) design
You think this is
good design? Good? I emphatically disagree. User interfaces that anticipate a user's intention are
too often wrong and waste far more time than they "save". Counter-productive.
I know full well that my strategy is ready to run but I don't want it to. Your alternate "solution" to deliberately cause a compile error to prevent auto execution behavior proves my point. Bottom line? I agree with Kevin that auto-execution is a bad idea.
In a similar "I know better than you" interface design,.the "Save Parameters" button below the Parameters starts grayed(?) when you open a strategy, then if you run a backtest
and change a parameter, activates but changes to "Re-run Backtest". Only after you re-run the backtest does it change to an activated "Save Parameters" function. Really? I may have already run those parameters and know their result. I just want to go back to them and save them. Nope. Got to run a backtest first before I can "Save Parameters".
Size:
Color:
By changing "Scale", "Data Range", or "Position Size", the user clearly instructs the program to re-run the Strategy. It'd be utterly confusing if those changes were left without response as these dropdown boxes reflect the actual, already applied values. So if the user doesn't want a Strategy to run, he'd click a DataSet folder name and it won't run (assuming he doesn't change the dropdown boxes).
Size:
Color: