As a result of some of the recent threads, two things stick out that I would like to request for a future release. Both are architectural issues, but should be pretty easy ones to handle.
#1 is that the system not consider configuration complete until after OnStartUp() has been processed. This is important, because it is the only way to allow the code to participate.
OnStartUp() is the first time that the code has access to the configuration information the user set in the Indicators dialog, and so it is the first time the code can react to the user's choices. The code should be able to do any configuration thing there, and have the rest of the system recognize it. OnStartUp() should be able to add or remove plots, add or remove lines, change colors, and in general do any configuration type of action.
Many indicators, especially the common very simple ones,do not need this. However you do not have to get much more complicated before it is pretty essential. As just one example, consider writing a moving average ribbon indicator and allowing the user to choose how many lines the ribbon should have. You cannot do that in any nice way today, but it would be pretty straight-forward if you could still add plots and lines in OnStartUp(). Another example is that the code does not know until OnStartUp() which plots should show in the Data Box, and how they should be labeled.
#2 is that the Data Box should be an object that is directly accessible. Controlling anything as a side effect of other actions is in general not a good design, in fact it is a red flag that normally means a pretty bad design. Especially when it means doing something to the other object that has no functional purpose other than to create the side effect.
For example, the only way to control selected plots visibility in the Data Box is by setting them Transparent. That means that (a) there is no way to suppress anything visible (like 16 plots making up a moving average ribbon) and (b) any plots set transparent (that would not otherwise be transparent) complicate the code quite a bit for no good reason. Even if my point #1 is addressed, so that there is no timing issue, having to make the plot lines transparent complicates the code a lot -- now I have to also figure out how to restore their color any time the Indicators dialog box is raised (otherwise their color in that dialog box shows up as transparent) and be careful that the saved color -- an internal variable, not a user parameter -- is serialized (which, according to recent information in one of these threads, is an unsupported activity).
Not only is all that complication a problem to code, and a source of bugs, but consider that when something gets complicated it is more often than not a sign of poor design. That is how I see controlling plot visiblitiy in the Data Box by the plot's transparency -- it forces my code to get complicated, and is a bad design.
-- EV
#1 is that the system not consider configuration complete until after OnStartUp() has been processed. This is important, because it is the only way to allow the code to participate.
OnStartUp() is the first time that the code has access to the configuration information the user set in the Indicators dialog, and so it is the first time the code can react to the user's choices. The code should be able to do any configuration thing there, and have the rest of the system recognize it. OnStartUp() should be able to add or remove plots, add or remove lines, change colors, and in general do any configuration type of action.
Many indicators, especially the common very simple ones,do not need this. However you do not have to get much more complicated before it is pretty essential. As just one example, consider writing a moving average ribbon indicator and allowing the user to choose how many lines the ribbon should have. You cannot do that in any nice way today, but it would be pretty straight-forward if you could still add plots and lines in OnStartUp(). Another example is that the code does not know until OnStartUp() which plots should show in the Data Box, and how they should be labeled.
#2 is that the Data Box should be an object that is directly accessible. Controlling anything as a side effect of other actions is in general not a good design, in fact it is a red flag that normally means a pretty bad design. Especially when it means doing something to the other object that has no functional purpose other than to create the side effect.
For example, the only way to control selected plots visibility in the Data Box is by setting them Transparent. That means that (a) there is no way to suppress anything visible (like 16 plots making up a moving average ribbon) and (b) any plots set transparent (that would not otherwise be transparent) complicate the code quite a bit for no good reason. Even if my point #1 is addressed, so that there is no timing issue, having to make the plot lines transparent complicates the code a lot -- now I have to also figure out how to restore their color any time the Indicators dialog box is raised (otherwise their color in that dialog box shows up as transparent) and be careful that the saved color -- an internal variable, not a user parameter -- is serialized (which, according to recent information in one of these threads, is an unsupported activity).
Not only is all that complication a problem to code, and a source of bugs, but consider that when something gets complicated it is more often than not a sign of poor design. That is how I see controlling plot visiblitiy in the Data Box by the plot's transparency -- it forces my code to get complicated, and is a bad design.
-- EV
Comment