How is called the OnBarUpdate method from Indicators?

[Fernand0]

Hey!

I'm trying to figure out how it is called every OnBarUpdate from the Indicators.

Based on NinjaScriptBase..

//
        // Summary:
        //     Forces the OnBarUpdate() method to be called so that indicator values are updated
        //     to the current bar. If the values are already up to date, the Update() method
        //     will not be run.
        public void Update();

I imagine it's added to NinjaScriptBase.NinjaScripts. But i don't know where and how.

[bltdavid]

Not sure what you mean.

Update() is used to "force" OnBarUpdate to run -- but Update() doesn't really force anything. It more or less
says, "Hey, Mr OnBarUpdate, if you have bars data waiting to send to the indicator, and you need to run, please
do so right now. If so, I'll wait while you finish."

Update() isn't called on every OnBarUpdate. That's not its purpose.

You, the Indicator programmer, would call Update() inside your code but only in certain limited circumstances.
For example, when you design a publicly visible Series and you want to write a public property to expose that
Series, you might want to call Update() inside the getter just before returning. Why? For callers who access
this property, it ensures that the indicator has processed all waiting bars data (via OnBarUpdate) before the
reference to your public Series is returned to the caller -- effectively ensuring that all values are up to date.

When you call Update (in those rare circumstances that need it), if no bars data are waiting to be processed
by the indicator, Update() doesn't do anything.

The actual execution of the OnBarUpdate() is an asynchronous event, and occurs as necessary, such as when
a bar closes -- OnBarUpdate() is invoked by the NinjaScript framework automatically, not by you.

When you call Update() it's really just a request made to the framework that says "please run OnBarUpdate()
right now if you have bars data waiting" -- but you really (almost) never need to do that.

You only need to think about Update() if you're writing an Indicator that will be used by other NinjaScript objects,
such as a Strategy, and only then for certain publicly exposed property types, such as a Series. Update() was
designed for these use cases -- other NinjaScript objects will benefit when your Indicator is guaranteed up to
date before the exposed property is accessed -- because, you, the programmer, called Update() on "behalf"
of those objects -- like a courtesy.

Take a look at @Swing.cs or @ZigZag.cs -- note how Update() is being used inside code that is meant to be
called by other NinjaScript objects.

[Fernand0]

bltdavid Thanks for your reply!

The actual execution of the OnBarUpdate() is an asynchronous event, and occurs as necessary, such as when
a bar closes -- OnBarUpdate() is invoked by the NinjaScript framework automatically, not by you.

Yes, i see the virtual OnBarUpdate from NinjaScriptBase which is inhereted to strategies and indicators.
Trigger that method for strategies is easy. Every time you create an Strategy you just add the NinjaScriptBase to NinjaScripts.
But! When you create an Indicator, how does it work?

[bltdavid]

bltdavid
Yes, i see the virtual OnBarUpdate from NinjaScriptBase which is inhereted to strategies and indicators.

Where are you looking?

bltdavid
Every time you create an Strategy you just add the NinjaScriptBase to NinjaScripts.
But! When you create an Indicator, how does it work?

What do you mean by "add the NinjaScriptBase to NinjaScripts" ??

It "works" because of inheritance, because C# is an OOP language, because
public classes such as Indicator and Strategy inherit from other classes inside
the NinjaScript framework -- this huge class hierarchy (purposely) hides the
low-level details you seek -- isn't it enough to know that OnBarUpdate() is an
asynchronous event and that Update() is a way to ask the framework to call
it for you?

It's also quite possible I'm not understanding your question ...

[bltdavid]

Remember, you don't call OnBarUpdate. You don't call your OnBarUpdate inside
your indicator, and you don't call anybody else's OnBarUpdate either.

Who calls OnBarUpdate?
The framework does. You add an indicator to a chart, and every time the chart
receives a tick, it makes sure all the indicators inside the chart get their OnBarUpdate
executed, but only according to "update-frequency" policy you assign to the indicator
via the 'Calculate' setting -- which is usually 'OnBarClose' -- lots of indicators don't need
to process every tick, they only need to process every bar.

There is a huge internet based process going on under the hood. The exchange produces
real-time data, which Continuum, Rithmic, Kinetick, et al, collect. Your NinjaTrader.exe
has connected to your data feed and receives data from it -- this happens because the
internals of the NinjaScript framework (for ex, when a chart is created) downloads that
data. Then the framework aggregates this data into the Bartype of your chart, such as
a Renko bar, or a Range bar, or a 5-minute bar, whatever, and then the framework calls
every indicator's OnBarUpdate on that chart, making the data digestible to each indicator
via the Open, High, Low, Close, Volume, and Time series ....

[Fernand0]

Where are you looking?

Metadata files of NinjaTrader Framework.

It "works" because of inheritance, because C# is an OOP language, because
public classes such as Indicator and Strategy inherit from other classes inside
the NinjaScript framework

I agree, but I'm asking how the indicator is added to the Collection which is used to call the OnBarUpdate.

Who calls OnBarUpdate?
The framework does. You add an indicator to a chart

Indicator are not always created by adding them to a chart. And that's my point, when you create them inside an strategy, you are not adding the indicator or its base classes manually.
So, how and where the indicator, created inside an strategy, is added to the list of NinjaScripts that have to be updated?

[Fernand0]

This is a vague version of the library..

[NinjaTrader_ChelseaB]

Hello Fernand0,

The data requests and instrument threads running behind the scenes are pumping information to subscriber threads and triggering the OnBarUpdate() method in constructed indicators and strategies by NinjaTrader.

Unfortunately, this is proprietary information in the core code of the application that we cannot provide to our clients.

[bltdavid]

Ah, now I understand your question.

Indicators accessed from a Strategy running on a chart are added to/accessed from
the same collection as the manual indicators added to that chart.

How does this work?
Magic. Just kidding. But in the same sense that magic is undocumented, so is the
auto-generated NinjaScript code at the bottom of every indicator.

When a Strategy invokes an indicator, such as EMA(14), it invokes the method defined
by the magic code for the "NinjaTrader.NinjaScript.Strategies" namespace, see the
bottom of @EMA.cs,

namespace NinjaTrader.NinjaScript.Strategies
{
    public partial class Strategy : NinjaTrader.Gui.NinjaScript.StrategyRenderBase
    {
        public Indicators.EMA EMA(int period)
        {
            return indicator.EMA(Input, period);
        }

        public Indicators.EMA EMA(ISeries<double> input , int period)
        {
            return indicator.EMA(input, period);
        }
    }
}

See the small 'i' in the call to "indicator.EMA(input, period)"? That small 'i' is
very important. Now, go take a look at the file @Strategy.cs, note the private
variable definition,

private Indicator indicator;

Again, note the big 'I' vs the small 'i' -- it's critical that you recognize that.
"Indicator" is a type, and represents a class, but "indicator" is an instance
variable that refers to an instance of type "Indicator".

"indicator" is assigned its value inside the constructor for the Strategy
class -- which means it has a value and becomes available for use before
the code at the bottom of @EMA.cs is executed by your strategy.

Remember, your strategy is derived from the Strategy class, so the constructor
for the Strategy class is guaranteed to run before your own strategy's constructor.

The purpose of the "indicator" variable is to access all the inner details of the
Indicator class. And inside the Indicator class (the magic code requires partial
to add methods named "EMA" to each class) the EMA method is creating a
new EMA object and adding it the 'cacheEMA' array -- but only if a an object
matching the same arguments did not already exist in the cacheEMA array.

[When studying this magic code, it's important that your eyes be able to discern
the difference between the EMA methods being defined and the EMA object
being created and stored in the cacheEMA array. The class named "EMA" and
methods named "EMA" defined in the magic code are separate and distinct,
and these names do not conflict with each other.]

You have to understand that when your strategy is calling EMA(14) it is really
calling "indicator.EMA" -- and since "indicator" is an instance of "Indicator" it
can call anything available in the "Indicator" class through that instance -- the
"indicator" instance calls the EMA method defined in the "Indicator" class. It
does this on behalf of your strategy -- all because of the auto generated
NinjaScript code at the bottom of each indicator. Thus, the same 'cacheEMA'
array contains EMA objects added to the chart, or called from Strategies, or
invoked from the MarketAnalyzer.

This is all undocumented stuff.

If you have NT7 installed, I recommend you study the auto generated code in
@EMA.cs over there instead. Couple that with the NT7 @Strategy.cs and you
can glean a lot more about what must be going on under the hood.

It's clear to me that NT engineers have become more sophisticated with their
NT8 auto generated code -- for ex, the new CacheIndicator<T> hides lots of
details that NT7 magic code used to expose.

[Fernand0]

Hello Fernand0,

The data requests and instrument threads running behind the scenes are pumping information to subscriber threads and triggering the OnBarUpdate() method in constructed indicators and strategies by NinjaTrader.

Unfortunately, this is proprietary information in the core code of the application that we cannot provide to our clients.

An alternative then? I'm asking how to make it work basicaly, i'm not trying to copy the framework or bring the company down.

[NinjaTrader_ChelseaB]

Hello Fernand0,

What are you trying to make work?

Indicators called by a strategy automatically have OnBarUpdate() called by NinjaTrader. You do not have to do this yourself.

Can you clarify the issue you are having?

When you mention:
"So, how and where the indicator, created inside an strategy, is added to the list of NinjaScripts that have to be updated?", this question is asking how NinjaTrader works internally behind the scenes. I cannot provide inner code where NinjaTrader is constructing instances of indicators and adding these to memory, doing data requests, and automatically triggering OnBarUpdate when bars update. None of this information is needed to call an indicator.

[Fernand0]

Hello ChelseaB,

The main problem is that NinjaTrader doesn't provide backtesting for addons, so basically i have to create a similar system.

Strategies are created and added, let's suppose to an event that triggers the OnBarUpdate method. So far, so good, is easy because everytime you create the strategy you have to subscribe that event.
But when you create Indicators (they need to be updated like the Strategies) the idea is to respect the object pattern like Strategy does, both classes have no idea what an Instrument is, they just receive data and update. The strategy is created manually, the indicators are not, they are created inside the strategies. That is the problem. I don't find a solution to trigger the "OnBarUpdate" of every Indicator.
One possible solution is to use a super static class that collects every single thing to be updated. But that is a problem when you want to create several strategies.
So I'm looking to do it in a different way.

[NinjaTrader_ChelseaB]

Hello Fernand0,

That is correct. NinjaTrader does not allow for backtesting addons.

Indicators called from a strategy will automatically have OnBarUpdate() triggered by NinjaTrader, you don't have to do this. We do this for you. You don't have to worry about triggering OnBarUpdate() in a called indicator.

But if you have a custom class (that is instantiated and not static) that is called by a script from OnBarUpdate(), then the strategy thread will be calling the custom class from OnBarUpdate() when NinjaTrader is triggering OnBarUpdate() in the strategy.

If you have custom events declared and custom event handlers this would be getting outside of what is supported by NinjaTrader.

[bltdavid]

That is correct. NinjaTrader does not allow for backtesting addons.

Which begs the question, can an Add-On enter trades?
(When I think of backtesting, I think of strategies doing automated trading.)

If backtesting is/was a big requirement for this NinjaScript object, is the choice
of even making it an Add-On the most appropriate?

I'm just confused why an Add-On would require much backtesting -- I'm more savy
with NT7 so I'm genuinely curious and interested about your NT8 Add-On issues ...

What does your Add-On do?

[NinjaTrader_ChelseaB]

Hello bltdavid,

Addons can submit orders in real-time only.

https://ninjatrader.com/support/helpGuides/nt8/submit.htm