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_Josh]

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]

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_Josh]

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.