Managing Indicator/AddOn Instances Within Another Indicator.

[StoneMan78]

Hello, I am trying to build out a framework to create a variety of anchored VWAP based indicators. To do this I have created an anchored VWAP class (VWAP8) where the anchor bar, anchor price, and number of bars the VWAP calculates for (duration) are accessible to other indicators/classes. The next part of this framework is a class (SimpleVWAPIndicator) which creates and manages a list of those anchored VWAP instances running on the chart. It determines the anchor bar, anchor price, and duration of each VWAP. The goal of this indicator is to create a framework where I can easily reference the values of other indicators in order to create anchored VWAP instances and determine their anchor bar, anchor price, and duration.

The issue I believe I have ran into here is that NinjaTrader does not support inheritance within the indicator namespace. So it is causing me problems trying to implement this idea. As you can see in the code below both programs currently fall under the Indicator namespace. So I am looking for a work around. A potential solution I was thinking of was moving VWAP8 to the AddOn namespace so to avoid that issue. I don't have much expirence with AddOn's and I think this topic may be delving pretty deep into some platform quirks so I was hoping someone on the know could give me some advice as to the viability and implementation of this potential solution.

[NinjaTrader_ChelseaB]

Hello StoneMan78,

This is correct, NinjaTrader does not support inheritance with Indicators or Strategies. This interferes with the optimizer and with the generated code wrappers.

We instead suggest using partial classes to share code. Below is a link to an example.

https://ninjatrader.com/support/forum/forum/historical-beta-archive/version-8-beta/83018-partial-class-does-not-work#post712245

Further, it is suggested to isolate shared code to a separate file, and if exporting an assembly, export the shared file as a separate assembly. Below is a link to a video.

https://drive.google.com/file/d/1D9qMVu1Ahb58Z82IVT0R7caTu0icg9nC/view?usp=share_link

[StoneMan78]

Thank you for the reply ChelseaB. The goal is for this indicator to be compatible with all other parts of NinjaTrader such as backtesting features in a safe and reliable way.

I don't want it just pointing to values from the AddOn but instead pulling those data series into a list within the indicator where they can be plotted and referenced. The individual VWAP lines generally don't matter to me. What is going to end up mattering is how they are grouped.

For example, one of the first things I want to apply to this framework to is attaching VWAPs to the swing high and swing low bars of the Swing indicator. What will matter to me is the two separate lists of swing high and swing low VWAPs. Each list can be drawn on the chart as it's own individual plot. The SimpleVWAPIndicator is me trying to establish a clear path towards making these lists of anchored VWAPs by starting with just one list and using simple logic to reduce the points of potential failure in the code.

I'm hoping to be able to apply the VWAP8 file to multiple projects including a drawing tool where the anchor bar is assigned from a simple click on the chart. So I really need a robust solution to build off of. In your opinion does a partial class accomplish this? Or could the logic I described above be made to work from the AddOn namespace?

[NinjaTrader_ChelseaB]

Hello StoneMan78,

Your VWAP8 file is an indicator. It can only be called as an indicator. You can call indicators from other indicators and from strategies. You cannot call an indicator from drawing tool script.

You can supply an indicator instance to a class and use any data series that is a child of that indicator.

Note, you have 'new VWAP8(CurrentBar, anchorPrice)'. This is incorrect. Do not use the new keyword when calling an indicator.

[StoneMan78]

Apologies for not framing my question correctly. I understand that the VWAP8 file I provided falls within the indicator namespace. And to keep it as such while achieving my desired logic a partial class within SimpleVWAPIndicator would be required.

My question is if I could change the namespace of the VWAP8 file to AddOn. Then successfully manipulate instances of that AddOn within the SimpleVWAPIndicator using the logic I described in my last response.

In general, can I manipulate instances of an AddOn within the Indicator namespace? Does NinjaTrader allow for this?

I understand that elements of both files would need to change to this.

If it can be done, how would you recommend proceeding given the files I have provided.

Thank you for your assistance, it is greatly appreciated.

[NinjaTrader_ChelseaB]

Hello StoneMan78,

Unfortunately, no, an indicator could not be an addon. You can share code between scripts with a partial class (such as making calculations for a series), but you would have to call an indicator method if you are wanting plot values, or drawing objects, or anything that is DataSeries or Chart dependent.

[StoneMan78]

Thank you for the clarification. It has helped a lot in me learning what permissible in NT programming. This project has taught me it's not everything in C# which is good to know.

I would like to add a feature request based on this. If a list of C# development methods and features that are not compatible with NinjaTrader could be added to the help guide that would be wonderful.

I came into this project assuming inheritance would work, and after many hours found out is was not compatible via the forums. I'm sure there are other advanced techniques that throw up unexpected road blocks to folks as well. If these could just be listed I'm sure it could save a lot of time and frustration.

Thank you.

[NinjaTrader_ChelseaB]

Hello StoneMan78,

I'll submit your request for consideration.

Thank you for your feedback.

[bltdavid]

This is correct, NinjaTrader does not support inheritance with Indicators or Strategies. This interferes with the optimizer and with the generated code wrappers.

Arguably, Chelsea is wrong. It just depends on your point of view.

When NinjaTrader says 'we do not support' something -- that always
needs context and, usually, some extra explanation.

Sometimes NT Support intentionally and deliberately leads the reader to
conclude 'unsupported' means something deeper than it really does.

Sometimes it means that the functionality is missing in the product, and
therefore a certain feature is not available. For example, in NT8 the
concept of 'Account Groups' is not supported (it was in NT7) but in
NT8 the functionality was removed, so many times Support will
describe this feature as 'unsupported'. Again, it's the context.

In other matters, such as partial classes or abstract base classes, the
functionality is present and works fine (perhaps with caveats, which
may have workarounds), but Support (usually) does not offer any kind
of help or assistance with the topic, and they describe this lack of help
as 'unsupported', which can lead the reader to conclude incorrectly the
functionality is missing, or does not work -- which is incorrect.

'Not supported' may mean the functionality is missing.
'Not supported' may mean assistance will not be provided.

It usually means one or the other, but not both.

-=o=-

Partial classes are 'supported' -- in the sense that Support will help you
with simple examples and try to answer your questions -- even to the
point of advising you of caveats, and workarounds for those caveats,
such as telling you to locate your partial classes in the AddOns folder
to avoid issues with the generated wrapper code created by the
NinjaScript compiler.

Abstract classes are 'unsupported' -- in the sense that Support will not
help you or advise you, only warn you don't do it. In the case of an
abstract class, the 'warning' against their use is due to issues with the
generated wrapper code. But the same advice for partial classes
(aka, put your partial classes in the AddOns folder) is never provided
as a workaround for abstract classes, even though the exact same
advice would solve the same exact problem.

You want to use partial classes?
NT Support says fine, here's some examples, and, btw, store your
partial classes in the AddOns folder to avoid issues with the compiler's
auto generated code.

You want to use abstract base classes?
NT support says nope, we have no examples, because the auto
generated code will cause you problems.

WTF?

In one case, Support says the auto generated code causes problems,
and that's why its unsupported. In the other case, they say the auto
generated code causes problems, but here's a workaround.

Tho auto generated wrapper problem is the same problem, despite
whether its partial classes or abstract classes!

See my point?

-=o=-

Why do partial classes get all the love?
(Especially when the suggested workaround applies to both.)

Or, more precisely, why do abstract classes get no love whatsoever
when you've already given plenty of love to partial classes?

Partial classes and abstract classes are similar, and solve similar
problems -- but the abstract base approach is more elegant and
solves more problems and provides more advantages.

Really, it is grave disservice for Support to continue the suppression
for abstract base classes.

-=o=-

Or, maybe I should just write a 'book', one of those little electronic
self-published thinga-ma-bobs, maybe sell it on Amazon, and make
some money off the continued head-in-the-sand approach taken
by Support.

It's exhausting doing combat with Support on this topic.

Sigh ...

[NinjaTrader_ChelseaB]

Hello bltdavid,

Unsupported means that the NinjaTrader Staff does not provide support for it.

With C# in NinjaScript there is a lot that is possible, however the NinjaTrader Staff does not support all of C#. You can choose do just about anything you would like in C#, as long as it does not remove any default functionality and is not malware. The NinjaTrader Staff in general provides support for what is documented in the help guide. Some things may not be documented, and our staff from time to time may have to state what is supported and what is not.

This means anything unsupported (or the Support Staff does not assist with) would done at the users own discretion, knowing the risk that this may cause intended behavior and that our staff cannot help with it.


When it comes to a stance on partial verses abstract classes; abstract classes are known to cause issues in some situations. Because of that the official stance is that these are not supported. With partial classes, this was the intended functionality all the way back to NinjaTrader 6.5. The UserDefinedMethods.cs file in NT7 was a template to get developers to put things in partial classes. In NT8 we just provide an example instead of directing users to use a premade file.