Exception raised when setting background color

[strategesis]

1) Raising the exception is non-deterministic: It only happens for certain unpredictable combinations of instrument, bar type, and days or bars back. Recently, the probability of the exception being raised has been relatively high in the case the TF futures contract using 133-tick bars.

2) The exception will only occur when there are two or more data streams used by the indicator, and only if an attempt is made to set the background color when BarsInProgress is greater than zero.

3) The same exact problem is also present in NT7 (of course, the code has to be different because of the differences between NT7 and NT8).

4) Here is the stack traceback for the exception:

Index was out of range. Must be non-negative and less than the size of the collection.
Parameter name: index
at System.ThrowHelper.ThrowArgumentOutOfRangeExceptio n(ExceptionArgument argument, ExceptionResource resource)
at NinjaTrader.NinjaScript.BrushSeries.Set(Int32 index, Brush value)
at NinjaTrader.NinjaScript.NinjaScriptBase.set_BackBr ush(Brush value)
at NinjaTrader.NinjaScript.Indicators.N1IndicatorBase .postUpdatePlots()
at NinjaTrader.NinjaScript.Indicators.N1IndicatorBase .OnBarUpdate()

5) Here's the slightly simplified code I use to set the background color:

	public enum BackgroundColorScope {
		IndicatorPanel,
		AllOtherPanels,
		AllPanels
	}
	
	public enum BackgroundColorMode {
		DoNotColor,
		Static,
		Dynamic
	}

	protected virtual void setBackgroundBrush() {
		
		Brush brush;
			
		switch (backgroundColorMode) {
			default:
			case BackgroundColorMode.DoNotColor:
				return;
			case BackgroundColorMode.Static:
				brush = staticBackgroundBrush;
				break;
			case BackgroundColorMode.Dynamic:
				brush = computeBackgroundBrush();
				break;
		}

		switch (backgroundColorScope) {
			case BackgroundColorScope.IndicatorPanel:
				BackBrush = brush;
				break;
			case BakgroundColorScope.AllOtherPanels:
				BackBrushAll = brush;
				BackBrush = staticBackgroundBrush;
				break;
			case BackgroundColorScope.AllPanels:
				BackBrush = brush;
				BackBrushAll = brush;
				break;
		}
	}

        protected override void OnBarUpdate() {
               ....... other code.....
               setBackgroundBrush();
               ........other code......
        }

[strategesis]

Bumping due to no response.

[NinjaTrader_PaulH]

Hello strategesis,

Thanks for your posts.

I will investigate and reply when I have further information.

[NinjaTrader_PaulH]

Hello strategesis,

Thanks for your patience.

Can you clarify what you are using for staticBackgroundBrush and computeBackgroundBrush();?

[strategesis]

staticBackgroundBrush is the backing variable for a user-configurable property of type Brush. By default, it's set to one of the SolidColorBrushes using Brushes.XXX, where XXX is one of the predefined Brushes.

The code resides in an abstract base class from which all of my indicators inherit. The computeBackgroundBrush() method is a virtual method which can be (and sometimes is) overridden in subclasses, so that they can compute a background color dynamically, bar by bar. The default implementation in the base class simply returns staticBackgroundBrush.

The exception is raised whenever the backgroundColorMode is either BackgroundColorMode.Static or BackgroundColorMode.Dynamic, and regardless of whether an indicator overrides the computeBackgroundBrush() method.

Does that answer your questions?

[NinjaTrader_PatrickH]

Hello strategesis,

Thank you for your patience.

We have been unable to reproduce this. Do you have any test files we can use to reproduce this exception?

[strategesis]

Patrick,

I have attached an indicator (coded just for this purpose) which demonstrates the problem. I have also attached the log file where the text of the exception can be found.

As I said above, the bug does not always occur--it is dependent on a) the bar types, b) the interval values, c) the number of days or bars back selected, d) today's date, and e) the instrument. This evening, I was able to reproduce the bug using the following settings:

Data Series (main chart) parameters:

ES 12-15
512 tick
7 days back

Indicator Parameters:

(Secondary) Bar Period Type: Minute
(Secondary) Bar Period: 15

[strategesis]

Patrick,

Just checking to make sure you saw the sample code I posted last week.

[NinjaTrader_Matthew]

I could reproduce and is a result of CurrentBar being -1 for the series you're trying to set the background brush for.

There are situations that can occur where OnBarUpdate will run for one series before the other series has been pooled. For example:

CurrentBars[0] = 2 minute
CurrentBars[1] = 1 minute

The Added Series will be ready before the Primary series, so you may run into a case where CurrentBars[0] = -1, but CurrentBars[1] would be 0.

In NinjaTrader 7, we would wait until all series was fully ready before it would start processing. This would sometimes causes other issues if you wanted to e.g., run some math functions on one series before the other series had met the bars requirement. NinjaTrader 8 has removed that restriction to allow for more flexible multi-series processing, but you'll need to be more aware of your CurrentBars before attempting to access.

To resolve in your case, simply check the Current bars[idx] against some value, such as BarsRequiredToPlot or at least 0 depending on your needs.

		protected override void OnBarUpdate() { 
			if(CurrentBars[0] < 0 || CurrentBars[1] < 0)
				return;		
			setBackgroundBrush();
		}

In other words, as long as CurrentBars[0] < 0, you should not be trying to access/ set information from the array.

Let me know if you still see errors with that run time check in place with your multi-series scripts.

[strategesis]

Mathew,

Issues remain:

1) The problem exists in NT7, not only in NT8. That would seem to invalidate your suggestion that the problem is due to changes in NT8.

2) The test code never attempts to access a Series<XXX> itself. Of course, your code may be doing that in order to set the background brush. But it seems to me that, in this case at least, that makes defending against the possibility of a not-fully-initialized series your responsibility, not that of the clients of your platform.

[NinjaTrader_Matthew]

Mathew,

Issues remain:

1) The problem exists in NT7, not only in NT8. That would seem to invalidate your suggestion that the problem is due to changes in NT8.

2) The test code never attempts to access a Series<XXX> itself. Of course, your code may be doing that in order to set the background brush. But it seems to me that, in this case at least, that makes defending against the possibility of a not-fully-initialized series your responsibility, not that of the clients of your platform.

I would need the specific scenario in NT7 to see what is happening there. I'm only commenting on what I could observe on the NT8 script you provided.

Developers of the platform have always needed to do run-time error handling. In discussing the changes that exposes this particular problem, it was discussed if there was something we could do to handle, but it was ultimately decide that silently eating programming issues to "hand hold" developers only serves to confuse what is happening under the hood.

Can you reproduce the problem in NT7 or NT8 with the current bars check I mentioned?

[NinjaTrader_Matthew]

Also... to prevent any further confusion, we'd need a much more simplified script.

- Add a Data Series
- Set the BackBrush for a series


Your code is doing much more than is needed to debug and may just confuse the scenario.

As a side note, conditionally adding/setting a bars type is not a concept we could support in NT7 or even in NT8. If you cannot reproduce without that conditionally added, that could be why you're seeing issues in NT7 and NT8 but ultimately would need the specific scenario to let you know. If you can reproduce without the conditional AddDataSeries() that would be great and I can definitely get that scenario into developers

[strategesis]

I have coded a much simpler indicator for NT7 which reproduces the problem. It's attached.

1) It does not contingently add a second input data series, but hard-codes adding a 15-minute secondary data series.

2) It simply sets the panel's background color to red, with no contingent logic. It literally does nothing else.

As I've mentioned above, reproducing the problem requires specific combinations of instrument, main chart bar type & period, number of days back, and current date.

For today, I found the following combination of settings which will reproduce the problem:

Instrument: CL 12-15
Main chart bar type & period: 512 tick
Days back: 9

[NinjaTrader_Matthew]

Thanks for putting that together today.

I can confirm what is happening in NT7 was the same thing in NT8: accessing a CurrentBar value which is -1.

I would need to make a slight correction to my previous comments:

Indicators : in NinjaTrader 7 started processing immediately, so you could definitely run into this scenario current one CurrentBars is -1 and not ready to be accessed. This has not changed with NinjaTrader 8

Strategies : in NinjaTrader 7 waited until BarsRequired would be met for all series before it ever called OnBarUpdate... this is changed in NinjaTrader 8 where Strategies now act like indicators acted in NinjaTrader 7-> They will start processing OnBarUpdate() immediately regardless if all series are ready - which will lead to scenarios where you may hit this error where CurrnetBar[idx] = -1.

That change above was irrelevant since we're dealing with an indicator so I apologize for getting off track -

Specific to your scenario with the indicator:

To test this I'd suggest eliminating tick data since that introduces a variable that is hard to catch and why it needs a precise combination of period and number of days back. This is easy to simplify is you run the Primary series which is greater than the secondary series. So your script where Added a 15 minute series, you can run your primary on a 30 minute series. That should reproduce the problem every time.

The result of that setup ends up with OnBarUpdate() being called for the 15 minutes added series first, but the 30 minute primary series is not "ready" and its current bar = -1, which then results in the index out of range error when you try to access the BackBrush for that primary series.

Simply adding the CurrentBars[idx] < 0 return resolves this in both versions.