Abstract classes : Indicator

[RanchoDinero]

The NT8 generated code attempts to create an instance of an abstract class such as an indicator, strategy etc, so it can't be compiled. NT7 recognized when a class in the hierarchy was abstract.

Without abstract classes it's not possible to factor code in an OO way (obviously) Can this be changed to the NT7 model? It's a critical issue for any framework development or for code with much complexity at all, in my view.

[NinjaTrader_ChelseaB]

Hello RanchoDinero,

I've given using abstract classes a test but I haven't run into any issues with the NinjaTrader generated code.

I was able to put this together and export it.

Does this import ok on your end?

If you add to a chart does it print to the output window ok?

[RanchoDinero]

Chelsea -

Thanks for the example, though that's not an abstract class. Please try this:

namespace NinjaTrader.NinjaScript.Indicators
{
public abstract class ClassTest : Indicator
{

}
}

Note the abstract keyword between "public" and "class".

[NinjaTrader_ChelseaB]

RanchoDinero,

Just a moment. You are trying to change the NinjaTrader framework of the indicator class itself?

(My example just demonstrates you can use your own abstract classes without issue. This does not involve changing the structure of of the NinjaScript code.)

This is not allowed. I'm guessing you are asking to make this allowed, is this correct?

[RanchoDinero]

This isn't changing the NT framework, it's only defining a class which inherits from Indicator (or Strategy or whatever) and implements some common functionality for a set of indicators, strategies or whatever which will be concrete down the inheritance chain.

This works in NT7. NT7 recognizes an abstract base class and does not generate code to instantiate it in the footer and abstract classes do not appear in the indicator/strategy lists at runtime (try it, you'll see).

Encapsulation only, as your example uses, takes away 2 of the 3 basic advantages of using objects, right? This isn't academic or esoteric ... it's just basic OO development. Your example requires a ton of glue code and re-scoping of methods and properties between the indicator and another class framework which is unnecessary with inheritance.

[NinjaTrader_ChelseaB]

Hello RanchoDinero,

Just to confirm, when you mention 'it's only defining a class which inherits from Indicator', does this mean that you are adding an additional class that inherits from the indicator?

Or you are trying to change the modifier of the already generated class of the indicator itself?

(When I am referring to NinjaTrader framework, I am referring to any NinjaTrader generated code such as the indicator class itself. Are you changing the NinjaTrader code or simply adding a sub-class that is abstract and trying to inherit from the indicator class generated by NinjaTrader?)

Attached is an example of an abstract class that inherits from the indicator base.

(Basically, what I'm getting at is that if you change the NinjaTrader generated code you will have issues. If you are adding to this code, then that should work.)


I want to be clear on what you are trying to do so that I may make a feature request for you. It sounds like you want to be able to modify the NinjaTrader framework (NinjaTrader generated code) and the process of how indicators are added to charts.

[RanchoDinero]

Chelsea -

Sure no problem and thanks. Not trying to change the NT generated code, just trying to create an abstract class which derives from Indicator, for the reasons in the prior post.

So to be clear...

Go ahead and create a new indicator using the following code and you'll see it won't compile due to the NT generated code, which trying to create an instance of this abstract class.

#region Using declarations
using System;
using System.Collections.Generic;
using System.ComponentModel;
using System.ComponentModel.DataAnnotations;
using System.Linq;
using System.Text;
using System.Threading.Tasks;
using System.Windows;
using System.Windows.Input;
using System.Windows.Media;
using System.Xml.Serialization;
using NinjaTrader.Cbi;
using NinjaTrader.Gui;
using NinjaTrader.Gui.Chart;
using NinjaTrader.Gui.SuperDom;
using NinjaTrader.Data;
using NinjaTrader.NinjaScript;
using NinjaTrader.Core.FloatingPoint;
using NinjaTrader.NinjaScript.DrawingTools;
#endregion

//This namespace holds Indicators in this folder and is required. Do not change it.
namespace NinjaTrader.NinjaScript.Indicators
{
public abstract class MyCustomIndicator : Indicator
{
protected override void OnStateChange()
{
if (State == State.SetDefaults)
{
Description = @"Enter the description for your new custom Indicator here.";
Name = "MyCustomIndicator";
Calculate = Calculate.OnBarClose;
IsOverlay = false;
DisplayInDataBox = true;
DrawOnPricePanel = true;
DrawHorizontalGridLines = true;
DrawVerticalGridLines = true;
PaintPriceMarkers = true;
ScaleJustification = NinjaTrader.Gui.Chart.ScaleJustification.Right;
//Disable this property if your indicator requires custom values that cumulate with each new market data event.
//See Help Guide for additional information.
IsSuspendedWhileInactive = true;
}
else if (State == State.Configure)
{
}
}

protected override void OnBarUpdate()
{
//Add your custom indicator logic here.
}
}
}

[NinjaTrader_Matthew]

Sorry for any confusion - if it worked in NT7 we'd expect it to work in NT8. This is a simple oversight in our wrappers generation and we will have it looked into.

[NinjaTrader_ChelseaB]

Hi RanchoDinero,

Thank you for clarifying this.

I've reported that changing the modifier of an indicator to abstract class did work for NT7 and is not working for NT8.

This issue is being tracked with id NTEIGHT-8219.

[mantak007]

Hello, would you please provide an update for this issue? In 8.0.0.8 I still cannot derive abstract class from Indicator, the NinjaScript generated code still tries to instantiate it. Is there any way, e.g. an attribute of my abstract class, which prevents NinjaScript from generating the unnecessary code? Thank you.

[mantak007]

I've been trying to work around the issue and tried to put the abstract class in AddOns folder as suggested in another thread, or to manually copy the source file into Indicators folder without opening it in the Ninjascript editor. Both ways work and the indicator can be used locally, however exporting it creates invalid .cs file in the export package, preventing the indicator from being imported on another machine. Could you please check the issue? Thank you.

EDIT: Seems the invalid .cs wasn't caused by the abstract class but by a custom namespace in one of the files included in export. For the simple case of having the abstract class in AddOns folder all seem to work OK.

[NinjaTrader_Matthew]

I've been trying to work around the issue and tried to put the abstract class in AddOns folder as suggested in another thread, or to manually copy the source file into Indicators folder without opening it in the Ninjascript editor. Both ways work and the indicator can be used locally, however exporting it creates invalid .cs file in the export package, preventing the indicator from being imported on another machine. Could you please check the issue? Thank you.

EDIT: Seems the invalid .cs wasn't caused by the abstract class but by a custom namespace in one of the files included in export. For the simple case of having the abstract class in AddOns folder all seem to work OK.

There has not been any work in the area of supporting abstract class generation, but I added a vote for you in SFT-341.

If I am understanding your edit correctly, you are able to work to meet your purposes by using it in the add-ons folder?

[mantak007]

Yes, it seems I persuaded NT to export my indicator derived from another abstract class correctly. I had problems with the custom namespace however, to me it seems the export works only under ideal conditions and is quite fragile. I understand this is of low priority for you if there is a workaround, but please report to the developers the export process needs to be reviewed and tested more when you have resources for it. And thank you for the vote.