How to expose data from within BarsType? For example, my custom Range bars have a variable range size and would like to expose current target price that will cause the bar to close. Or, I could expose buy sell ratio of current bar for all indicators on the chart to utilize.
I have shared static class between indicators and addons but when I do it from within BarsType it sometimes stops working.
A shared static class can work, but NinjaTrader’s bar cache and your static variables have separate lifetimes. NinjaTrader can load already-built historical bars from its cache without rebuilding that historical portion through your BarsType. If your dictionary is populated only inside OnDataPoint(), those writes may therefore not happen on every chart load. NinjaTrader support describes this cache-hit path explicitly in its explanation of chart loading.
That creates a pattern that looks intermittent:
Making the fields public does not make NinjaTrader persist them automatically.
Also, cached completed bars and locally stored source ticks are different things. Rebuilding bars from historical ticks already on disk can reconstruct your metadata without downloading everything again. NinjaTrader support distinguishes the bar cache from the historical tick/minute/day repository here.
You may need to use Wayback Machine to read the forum links unfortunately.
I would try to keep this instance-scoped rather than using a static bridge if the value belongs to a particular Bars object.
One useful starting point is that an indicator can access the BarsType instance associated with its Bars through Bars.BarsType. NinjaTrader’s own documentation demonstrates this pattern when another NinjaScript object reads Bars.BarsType.IsTimeBased.
So conceptually I would prefer:
the Bars instance -> its BarsType instance -> the state belonging to that specific bars series
rather than:
BarsType -> static/global storage -> indicator
The static approach can become ambiguous as soon as you have multiple charts, instruments, workspaces, or more than one instance of the same custom BarsType updating the same shared state.
The part I would verify before building around it is whether your custom public member on the BarsType-derived class remains directly accessible/castable from the consuming NinjaScript in the way you expect, since the documented BarsType API exposes a defined set of members.
As a quick experiment, I would put a very simple read-only value on the custom BarsType, then from an indicator inspect/cast Bars.BarsType after State.DataLoaded and read it from there. NinjaTrader specifically warns against accessing Bars members before State.DataLoaded.
If that works reliably, the target price or current buy/sell state stays attached to the correct BarsType instance and you avoid the lifecycle/collision problems of shared static state.
If it does not, I would avoid falling back immediately to one global static variable. At minimum the bridge would need to be keyed by the actual Bars/instrument/period instance and cleaned up with its lifecycle.
I’d be interested to know whether a direct cast of Bars.BarsType to your custom BarsType works in your case.
I would try to avoid the shared static class for this if the value conceptually belongs to a specific Bars instance.
One useful distinction is that the indicator already has access to the BarsType associated with its Bars object through Bars.BarsType.
NinjaTrader itself documents this pattern for reading BarsType state such as IsTimeBased, so for a custom BarsType I would first test whether the runtime instance can be cast back to your custom BarsType and expose the value there.
Conceptually:
var myBarsType = Bars?.BarsType as MyCustomRangeBarsType;
if (myBarsType != null)
{
double target = myBarsType.CurrentTargetPrice;
}
with CurrentTargetPrice exposed as a public read-only property on the custom BarsType.
I would only access it after the Bars object is available (State.DataLoaded or later / OnBarUpdate), since accessing Bars too early in OnStateChange() is specifically something NinjaTrader warns against.
The part I would test carefully is whether NinjaTrader is giving the indicator the same BarsType instance that is actually building that chart’s Bars object. If it is, this avoids the biggest weakness of a static store: values from multiple instruments, chart instances or Bars configurations colliding with each other.
If direct instance access turns out not to be reliable for a custom property, I would still prefer an instance-keyed registry over a single shared static value — for example keying by the actual Bars instance plus instrument/period — especially if several charts can use the BarsType simultaneously.
Your buy/sell-ratio example would be a good test case because it changes while the current bar is forming, so it should expose fairly quickly whether the indicator is seeing the live BarsType instance or only reconstructed/static state.