NT8's ChartControl.Indicators collection

[Zapzap]

Is there a way to get the values of the indicators attached to the chart?

if (CurrentBar == Bars.Count - 2)
            {
                foreach (Gui.NinjaScript.IChartObject thisObject in ChartControl.Indicators)
                {
                    NinjaScriptBase ib = thisObject as NinjaScriptBase;
                    Print(ib.Name + "\t" +ib.Value[0].ToString());
                }
            }

This codechunk put into onBarUpdate returns only zeroes. Getting actual IndicatorBase objects from ChartControl.Indicators used to work in Nt7. I wonder how to do it in NT8.

And there is a strange phenomena:

if (CurrentBar == Bars.Count - 2)
            {
                foreach (Gui.NinjaScript.IChartObject thisObject in ChartControl.Indicators)
                {
                    NinjaScriptBase ib = thisObject as NinjaScriptBase;
                    for (int c = 0; c < ib.Value.Count; c++)
                    {
                        Print(ib.Name + "\t" + ib.Value[c].ToString());
                    }
                }
            }

Throws an invalid index error. So even if the count is okay, not even the index 1 value can be checked.

[koganam]

Is there a way to get the values of the indicators attached to the chart?

if (CurrentBar == Bars.Count - 2)
            {
                foreach (Gui.NinjaScript.IChartObject thisObject in ChartControl.Indicators)
                {
                    NinjaScriptBase ib = thisObject as NinjaScriptBase;
                    Print(ib.Name + "\t" +ib.Value[0].ToString());
                }
            }

This codechunk put into onBarUpdate returns only zeroes. Getting actual IndicatorBase objects from ChartControl.Indicators used to work in Nt7. I wonder how to do it in NT8.

And there is a strange phenomena:

if (CurrentBar == Bars.Count - 2)
            {
                foreach (Gui.NinjaScript.IChartObject thisObject in ChartControl.Indicators)
                {
                    NinjaScriptBase ib = thisObject as NinjaScriptBase;
                    for (int c = 0; c < ib.Value.Count; c++)
                    {
                        Print(ib.Name + "\t" + ib.Value[c].ToString());
                    }
                }
            }

Throws an invalid index error. So even if the count is okay, not even the index 1 value can be checked.

ref: http://ninjatrader.com/support/helpG...indicators.htm

[Zapzap]

Even if I cast it to IndicatorRenderBase (which seems to be derived from NinjaScriptBase), or using that directly in the foreach, the result is the same. It's not caused by my cast. (If this is what you reffered to with the link - I couldn't learn any other useful differences from there)

So while I can reach some variables from the attached indicators, not all of them. Not the correct values at least. As I said this worked well in Nt7.

[NinjaTrader_DaveI]

Are you still checking through IChartObjects after viewing the link koganam shared? Do you see better results using the sample from that page, referencing IndicatorRenderBase objects inside of a specific instance of ChartControl instead, or do you see the same error?

[koganam]

Even if I cast it to IndicatorRenderBase (which seems to be derived from NinjaScriptBase), or using that directly in the foreach, the result is the same. It's not caused by my cast. (If this is what you reffered to with the link - I couldn't learn any other useful differences from there)

So while I can reach some variables from the attached indicators, not all of them. Not the correct values at least. As I said this worked well in Nt7.

Your syntax is querying for IChartObject instead of for IndicatorRenderBase. I have not yet looked deeply enough to know if IndicatorRenderBase is derived from IChartObject.

[Zapzap]

I tried all possible variations I could come up with. All is returning 0 as value. To be more specific it seems as if it returned the value of the first bar of the chart, and didn't update. Here is another block of code, I built on that sample:

The results are exactly the same 0 for value[0], the same index out of bounds if I try to cycle through Value indices, other variables of the indicator are reachable fine. (The names for example come through nice with all of NinjaScriptBase, IChartObject, IndicatorBase, IndicatorRenderBase)

So the problem is not with casts (and it shouldn't be, since the basic variables (like name and the Value array) is coming from the topmost class, which is NinjaScriptBase).

 if (CurrentBar == Bars.Count - 2)
            {
                foreach (NinjaTrader.Gui.NinjaScript.IndicatorRenderBase irb in ChartControl.Indicators)
                {
                    Print(irb.Name + "\t" + irb.Value[0].ToString());
                }
            }

[NinjaTrader_Matthew]

I tested this briefly and was surprised to see that worked in NinjaTrader 7. We have no gurantee that certain behavior or implementation would work through versions on undocumented items. This happens to fall into that category. In NinjaTrader 8, the Values will be 0 unless accessed in realtime. I don't foresee this changing based on this one use case, but to get you a solution - we'll see if we can find a way for you to access those values historically in another manner in NinjaTrader 8. We'll get back to you on this shortly. If we find any bugs along that way, we'll let you know.

[Zapzap]

Thank you very much for this reply Matthew! I really appreciate it.


We have no gurantee that certain behavior or implementation would work through versions on undocumented items. This happens to fall into that category.

I understand this. Although now it is documented, and I don't think it's an extreme use: if you can reach an actual indicator object, it seems evident that you can get the values of it: at least it's plotted somehow. Don't get me wrong here: I am not pushing or anything, just trying to make eg. the documentation better.

We'll get back to you on this shortly. If we find any bugs along that way, we'll let you know.

Thank you very much! It would be great to know such an info.

[NinjaTrader_Matthew]

You are right now that the ChartControl.Indicators is documented in NT8 at this time, we definitely have room to improve this item to set expectations on how it can be used. Thanks for bringing this particular item to our attention. Fwiw, it is performance optimization for which the values would be 0 in that State.

[koganam]

I tested this briefly and was surprised to see that worked in NinjaTrader 7. We have no gurantee that certain behavior or implementation would work through versions on undocumented items. This happens to fall into that category. In NinjaTrader 8, the Values will be 0 unless accessed in realtime. I don't foresee this changing based on this one use case, but to get you a solution - we'll see if we can find a way for you to access those values historically in another manner in NinjaTrader 8. We'll get back to you on this shortly. If we find any bugs along that way, we'll let you know.

Really? So does that mean that the information in the HelpGuide is incorrect?

I first (as far as I know) showed this for NT7 more than a year ago (with the usual caveats about it being unsupported then). ref: http://ninjatrader.com/support/forum...d.php?p=377081

When I first saw the documentation, I assumed that as you are now supporting access to ChartControl, this would be an almost trivial use. I am a bit surprised to hear that it is still in unsupported territory.

[NinjaTrader_Matthew]

Really? So does that mean that the information in the HelpGuide is incorrect?

I first (as far as I know) showed this for NT7 more than a year ago (with the usual caveats about it being unsupported then). ref: http://ninjatrader.com/support/forum...d.php?p=377081

When I first saw the documentation, I assumed that as you are now supporting access to ChartControl, this would be an almost trivial use. I am a bit surprised to hear that it is still in unsupported territory.

ChartControl is documented, and we did specifically document the ChartControl.Indicators collection, but there are some caveats that come along with properties within this collection which are unknown at this time.

We understand that there are several use cases to expose certain information for indicators that currently exist on the chart, and we have documented the ChartControl.Indicators for those purposes such the indicator.Name, indicator.Calculate in the help guide.

- however there are some things that will not be available depending on the state of the indicators, which we're still learning ourselves as we run into various requirements. We'll append documentation as these use cases come to light.

[NinjaTrader_DaveI]

We have come up with a workaround which should provide the results that zapzap is looking for, although it does not make use of the actual Indicator object on the chart.

In the attached code, we first set up a new List of Indicator objects. Then, in State.Historical, we instantiate a new copy of any indicators which are in the ChartControl.Indicators collection. Next (and this is where we step into undocumented territory), we use a hidden method named SetInput() to set the input of our new Indicators to the same input as the indicator we are running.

This essentially sets up an identical copy of the indicators which were not directly accessible in State.Historical, using the same input and parameters, which should theoretically provide you with the same plot and property values at the same times.

[koganam]

We have come up with a workaround which should provide the results that zapzap is looking for, although it does not make use of the actual Indicator object on the chart.

In the attached code, we first set up a new List of Indicator objects. Then, in State.Historical, we instantiate a new copy of any indicators which are in the ChartControl.Indicators collection. Next (and this is where we step into undocumented territory), we use a hidden method named SetInput() to set the input of our new Indicators to the same input as the indicator we are running.

This essentially sets up an identical copy of the indicators which were not directly accessible in State.Historical, using the same input and parameters, which should theoretically provide you with the same plot and property values at the same times.

First let me say that I am thankful and impressed that you would actually go so deep into the code so as to be able to provide a workaround, but I still have to criticise this. Sorry.

I love performance optimization, but not when it seems to result in what looks like skipping processing rules. Will it not make more sense to simply ensure that if an object is instantiated, NT waits for the constructor to return a fully formed object before going on? Sure, it does mean that some of our more fancy operations will mean a longer load time, but at least then we have objects that behave the way we would expect, instead of having to make these ad hoc workarounds that you kindly have to find and provide.

This whole thing begins to remind me of ETFVoyageur's complaints about how objects are not being fully constructed in the process flow. I am beginning to think that he was not just cavilling; maybe because I am getting to agree more and more with him that this may not be as obscure/trivial as I was at first inclined to think.

This smells way too much like a kludgy hack.

[NinjaTrader_DaveI]

Thank you for sharing your thoughts. I can understand your point of view. We're going to log this as a feature suggestion so we can start to track any further discussion surrounding this and similar cases. If it continues to come up, then it could be worth revisiting, but as it stands, it was never intended for these types of objects to be accessed at such an early State. (SFT-904)

[Zapzap]

First of all: hats off for the quality of support on this one. I always hoped that with opening up more of NT, we may get some specialized support. It seems that I was right with this, Thank You, I love this direction.

Secondly I need to agree with everything koganam said: with opening up and providing support for such, I can say, deep feautres I would think that the best approach would be to make the platform as robust as possible. It may be (and I hope) that this is some special spots I bumped into and a workaround will do the job.
Again, don't get me wrong, I haven't been on Nt8 for too long: so far I liked what I saw and I hope that users will like it as well so you can advance further with the userbase, who are Nt's most valuable asset imho.