Plots[].PlotBrushes[]

[QuantKey_Bruce]

Plots[0].Brush exists and is the brush/color assigned to the first plot in the indicator properties.
PlotBrushes[0][x] exists and is the brush/color that has been overridden on that same plot, x bars back.

The problem with this is if you have lots of plots, or if you copy/paste a code block in from another indicator that has let's say plots 0..10, and now the plots need to be renumbered to indices 11..21... so you end up having to do busywork to fix all this.

Typically, there are named properties such as MyPlot that alias to Plots[0] so you don't type Plots[0] in the code, you type MyPlot.

Suggestion: there should be a property Plots[0].PlotBrushes[x] which provides access to the PlotBrushes[] array for the right plot - this way you can do MyPlot.PlotBrushes[x] directly without knowing which index the plot is.

That would save a good bit of "refactoring" time when developers are doing a task like combining all the functionality from two indicators into one and they have to fix all the PlotBrushes[index] references.

[eDanny]

I believe this was talked about years ago as a common sense code change but it obviously never went anywhere.

[QuantKey_Bruce]

I believe this was talked about years ago as a common sense code change but it obviously never went anywhere.

Well, there's no time like the present to make it right. This is not a breaking change - it would be easy for NT to add this and it just makes sense.

[NinjaTrader_Jesse]

Hello QuantKey_Bruce,

I will put in a feature request for this, if there is already one your vote will be added. This is likely something that would not be implemented though based on the situation described. If you change the plots that will effect other parts of a script and not just the PlotBrushes collection. You would need to update anywhere you set the plots, and public properties that use Values collection, anywhere you use Plots[x] to get any plot properties. Generally changing the plots in an already working script is a code breaking change that requires manual intervention to ensure the script still works right.

[eDanny]

Hello QuantKey_Bruce,

I will put in a feature request for this, if there is already one your vote will be added. This is likely something that would not be implemented though based on the situation described. If you change the plots that will effect other parts of a script and not just the PlotBrushes collection. You would need to update anywhere you set the plots, and public properties that use Values collection, anywhere you use Plots[x] to get any plot properties. Generally changing the plots in an already working script is a code breaking change that requires manual intervention to ensure the script still works right.

The issue is the convenience of knowing what plot brush affects which plot. Easy if by name. Just like naming the plot dataseries so that the plot doesn't have to be accessed in code with Value or Values. This should be a no brainer fix. The issue isn't with working code per se, but is applicable to developing code.

[QuantKey_Bruce]

Hello QuantKey_Bruce,

I will put in a feature request for this, if there is already one your vote will be added. This is likely something that would not be implemented though based on the situation described. If you change the plots that will effect other parts of a script and not just the PlotBrushes collection. You would need to update anywhere you set the plots, and public properties that use Values collection, anywhere you use Plots[x] to get any plot properties. Generally changing the plots in an already working script is a code breaking change that requires manual intervention to ensure the script still works right.

NinjaTrader_Jesse, I apologize but I must not have explained this clearly. I'll put together an example that demonstrates what I mean and post it to clarify.

[QuantKey_Bruce]

This suggestion has been replaced by a more general and comprehensive idea at https://forum.ninjatrader.com/forum/...shes-available.