Indicator inheritance and Ninja code generation question

[GaryAlbers]

A couple questions about inheritance and ninja's code generation. A little
back ground first:

I have 1 indicator that I am splitting into 2 different visual representations. The 2 new indicators will share the same core calculations and parameters. Each new indicator will also have some additional parameters.

I had no problem creating the base indicator with all of it's parameters.
I then created the new indicator that extends the new base indicator and
added the parameters to the new indicator unique to it's visual presentation.

Both indicators compile correctly and when I place the new indicator, (that extends the new base indicator), on a chart it also draws correctly and all the parameters show up correctly in the property panel.

However, when I created a strategy that used the new indicator, the
strategy had a compiler error which was a complaint about the number of parms required to construct the indicator.
Upon deeper inspection into the code generated by ninja, I noticed that
the construction of the new indicator only took in the parameters defined in that extended class. It did not take into account the inherited parameters of it's base class.

This seemed strange because when the indicator is on a chart, the
property panel properly shows all the parameters, even the inherited ones.

I also noticed that if I put the parameter code in the extending class, BUT COMMENTED OUT, then ninja recognizes them and generates the constructor correctly.

Can ninja's code generator be made to look up the inheritance chain for all parameters?
Shouldn't ninja ignore commented out code?
Is there something more I have to code in the extending class to make
ninja's code generation notice the inherited parameters?

Thanks,
Gary

[NinjaTrader_JoshP]

Gary,

I am unaware of how you are exactly coding this, but wouldn't it just be easier to expose properties that you want to access on your base indicator and call them from your addon indicator?

[NinjaTrader_Ray]

I suggest not creating a new indicator based on inheritenace from our own class. Not sure if this would work or not but for sure we will not support this if it does not.

[GaryAlbers]

Need more info...

Thanks Josh and Ray for responding, but I need more info.

1) Ray, are you saying I should not code any indicators or strategies
using inheritance?

2) Josh, I do have properties exposed in base indicator and are using
them in extending indicator. The 2 indicators only share their base calculations but they plot totally different. One indicator has 24 plots,
the other has 5 different plots. Creating a base indicator and extending
it 2 different ways seemed like the best way to do it.

3) Is there any documentation describing ninja's code generation (what
it looks at, what are the pieces it generates, how are each of the methods
intended to be used)?

4) Why would the code generation process use commented out property
code when creating the indicator creation code?

BTW, the indicators are working, in that I have 2 separate classes
extending a base class. They each plot differently.
However, the main irritation is the hack I had to use to get the
extending indicator to properly get it's code generated so a strategy
could call it. (I have a bunch of property accessors coded in the base
class and I had to also code them again, but they are commented out,
in the child class in order to get the right generated code.)

Regards,
Gary

[NinjaTrader_JoshP]

3 & 4) Sorry Gary. There is no documentation on the method you are approaching it with. Unfortunately like Ray said, this is beyond the level of support we can offer.

[alex.nt]

It seems that the same issue persists in 2013, i.e. it is not possible to re-use properties defined in the base class in descendant classes because NT cannot properly generate auto-generated methods for the indicator then.

The hack Gary described would obviously overwritten any time indicator is compiled, so while it works, it is irritating indeed

I also tried to use virtual properties but it appears that NT code generator takes 2 first words from property definition so it results with "override bool" or the like instead of "bool ParamA" in constructor, which ruins all the thing.

Anyone could suggest the best practice for indicator inheritance then? Should it be used at all while developing indicators?

[NinjaTrader_Joydeep]

Hello alex.nt,
I will leave the thread open for our forum member as this is beyond what we could support.

[GaryAlbers]

alex.nt,

Inheritance does work, you just have to live with the code generation quirk.
You will have to decide for yourself if you want to use inheritance since it is 'not supported'.

I have settled on a combination of using inheritance, 'partial' class definitions and a utility classes in a name space that I include with a using statement.

Gary

[alex.nt]

Of course the inheritance does work but I wonder how to avoid re-implementing the properties in the descendant indicators without your hack as this is the [only] problem with indicator inheritance. It would be great if someone knew a workaround and shared their knowledge.

Perhaps, this can be added to wish list for next NT version.

[ntbone]

I have been creating indicators and would like it if one could create a base class that could reuse code. It is challenging to define common functionality for a set of indicators without having to copy code.

[NinjaTrader_ChrisL]

Hi ntbone, thanks for your post.

You can use the "UserDefineMethods.cs" file for re-usable code. This will compile any methods into the NinjaScript namespace.

[ntbone]

I want functionality way beyond just a method. A core set of functionality for a base class of an indicator may include local member variables, functions, properties etc...that are common to a set of indicators.

I have had no issue adding any amounts of custom code in their own .cs files to my NinjaTrader. The difficulty with Indicators is the extra processing used by code generation. Also problematic with Indicators is that they are automatically added to the menus.

Drawing tools for example, give the ability to decide whether they are displayed in the drawing menu. I can create a base class drawing tool that has common functionality and then derive any number of specific classes from that base class without problem.

Further, if I create an abstract class derived from Indicator, the code generation results in compiler errors. As a feature request it would be super helfpul to

• Abstract classes derived from indicator do not get code generation, and also do not get added to the indicators list.
• Classes derived from indicator regardless of the class depth are handled properly.

For example

public abstract class MyIndicatorBaseClass: Indicator {}  // doesn't get code generated, doesn't show up in the menus

public class MyConcreteClass: MyIndicatorBaseClass {}  // code generated, added to menus, and
                                                       // anything in MyIndicatorBaseClass like properties etc....
                                                       // pertaining to code generation will be automatically included in the code generation.

[bltdavid]

I want functionality way beyond just a method. A core set of functionality for a base class of an indicator may include local member variables, functions, properties etc...that are common to a set of indicators.

I have had no issue adding any amounts of custom code in their own .cs files to my NinjaTrader. The difficulty with Indicators is the extra processing used by code generation. Also problematic with Indicators is that they are automatically added to the menus.

Drawing tools for example, give the ability to decide whether they are displayed in the drawing menu. I can create a base class drawing tool that has common functionality and then derive any number of specific classes from that base class without problem.

Further, if I create an abstract class derived from Indicator, the code generation results in compiler errors. As a feature request it would be super helfpul to

• Abstract classes derived from indicator do not get code generation, and also do not get added to the indicators list.
• Classes derived from indicator regardless of the class depth are handled properly.

For example

public abstract class MyIndicatorBaseClass: Indicator {} // doesn't get code generated, doesn't show up in the menus

public class MyConcreteClass: MyIndicatorBaseClass {} // code generated, added to menus, and
// anything in MyIndicatorBaseClass like properties etc....
// pertaining to code generation will be automatically included in the code generation.

I believe all of this is already possible in NT7 ... I don't seem to have any problems doing the things in your list

[NinjaTrader_ChrisL]

Hi ntbone, thanks for your post.

I will test further and submit a new feature request for this if one does not already exist. Currently, it's not supported by the NinjaScript team but that does not mean you can't do this, given there might be undocumented pitfalls and limitations.

Kind regards.