What does NinjaTrader mean by 'inheritance is not supported'?

[jeronymite]

Whilst I agree with the sensible comments from bltdavid, ntbone and QuantKey_Bruce, in the context of the current implementation, the "elephant in the room" here (in this particular invocation of the discussion anyway) is that the current Desktop platform is using years-ago obsolete versions of the Actipro Editor, C#, .NET and other underlying infrastructure. Bring those up-to-date, and then see where the issues lie. They may be resolved or, at the very least, more easily "supported". Short of buying the company and doing it ourselves, what does it take for this to happen?!

Thanks.

[NinjaTrader_ChelseaB]

Hello ntbone, Bruce, jeronymite,

Yes, these have already been requested.

The request for supporting abstract classes is being tracked with ID # SFT-341.

The request for supporting inheritance with indicators and strategies is being tracked with ID # SFT-5158.

The request for updating NinjaTrader to use the latest .NET and C# versions is being tracked with ID # SFT-3124.

I will be happy to add your votes to these.

[jeronymite]

NinjaTrader_ChelseaB Please advise when each of these requests was first recorded.

Thanks.

Update [2023-04-01, NOT April Fool's post!]:
In the absence of any update from NinjaTrader, the following dates can reasonably be inferred from historical postings:

• The request for supporting abstract classes is being tracked with ID # SFT-341. <<< 2007-ish [16 years ago]
• The request for supporting inheritance with indicators and strategies is being tracked with ID # SFT-5158. <<< 2022-ish [last year]
• The request for updating NinjaTrader to use the latest .NET and C# versions is being tracked with ID # SFT-3124. <<< 2015-2016-ish [7-8 years ago]

Accurate dates from NinjaTrader always welcome.

Conclusion: Adjust your expectations accordingly!

Thanks.

[ETFVoyageur]

I know this is an old thread, but I found the thread helpful so I want to add to ntbone's comment

If you want your indicator to generate the code, it needs to derive from something with the word "Indicator" in the name, and it must be in the same line as the class declaration.
...
I will name my common base class with the name "Indicator" somewhere in it

You need not name your base class that way if you use the fully-qualified inheritance. This allows unlimited flexibility in naming your base class. For example, the magic code will be generated for the following:

    public class VsaChartData : NinjaTrader.NinjaScript.Indicators.Vsa_Base
    {}
​

Second, about the workaround of putting ": Indicator" on the second line -- that does indeed seem to cause the system to believe the code is not an indicator. Not only does that suppress generating magic code (crucial for an abstract class) but it also has the often-requested beneficial side effect of not including that class as an available indicator in the indicators dialog.

I worry that especially the next-line trick is implementation-dependent and could be seen by some well-meaning developer as a "bug" to get "fixed" in some future release. Furthermore, the parsing evidently sets not-an-indicator when it fails to find "Indicator" in the first line of the declaration. It would seem to be a very simple matter to set the same condition when it sees the word "abstract" because no abstract class can be an indicator. In other words, to be classified as an indicator (to generate magic code and to be included in the list of indicators in the dialog) it must (be derived from Indicator) && (not be abstract). This may not help non-abstract base classes, but let's at least get the simple fix done.