What are the ways I can limit a script from automatically starting after changing a setting?
Author: KEVINP
Creation Date: 10/13/2015 6:12 PM
profile picture

KEVINP

#1
My last question:

http://www.wealth-lab.com/Forum/Posts/How-do-I-interrupt-a-strategy-like-a-test-stuck-in-a-loop-or-a-test-not-finished-that-is-currently-running-37947

leads me into this question:

What are the ways I can limit a script from automatically starting after changing a setting?

I know there are a couple of posts that address similar issues (and the links in the post) like this one:
http://www.wealth-lab.com/Forum/Posts/Supression-of-automatic-execution-of-Strategy-35406

However, I cannot seem to find exactly my issue, which is: it seems like every setting I change results in the script auto running. For example, if I change "Scale", "Data Range", and "Position Size" the script auto runs. I am in testing and I am not ready for the script to run.

If I click a DataSet folder name, then it starts to auto run on all the symbols in the DataSet. I am in testing still, and I am not ready for the script to run every time I click something.

Thank you for any help.
profile picture

Eugene

#2
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.
profile picture

KEVINP

#3
Okay Thanks. I have seen what you are saying before, and will now adopt your suggestions.
profile picture

LenMoz

#4
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".
profile picture

Eugene

#5
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).
This website uses cookies to improve your experience. We'll assume you're ok with that, but you can opt-out if you wish (Read more).