Missing the automatically generated magic code

[ETFVoyageur]

I have an indicator that I just noticed is missing the wrapper code that NinjaTrader puts at the end of the file whenever it is compiled. The other odd thing is that compiling just adds a few more blank lines at the end of the file. Recompiling with no code changes does not cause any extra lines; compilations after the source has been changed do generate such lines.

The indicator is working fine for me as is; I can see no ill effect from not having the wrapper code. Nevertheless, I presume there is a good reason for that code so I can't help wondering whether this is a problem that needs to be fixed.

How serious is the lack of wrapper code, and is there any way to find the problem without needing to do something time-consuming such as deleting source code until I find what is causing the effect?

I don't think there is anything odd about the code other than it has no properties (I'm about to add some).

[NinjaTrader_ChelseaB]

Hello ETFVoyageur,

May I confirm the indicator is directly inheriting from the : Indicator class?

May I confirm the class is within the NinjaTrader.NinjaScript.Indicators namespace?

Do you have any custom namespaces declared above the class declaration?

Do you have the indicator open in the NinjaScript Editor and are you compiling from the NinjaScript Editor (and not a 3rd party editor)?

May I confirm you are using 8.1.3.0?


"How serious is the lack of wrapper code"

The generated code is what allows other scripts to call this indicator and specify parameters, as well as specify or not specify an input series, and make the script usable in the market analyzer, superdom, strategy builder, etc.

[ETFVoyageur]

Thanks for your reply and for the explanation of the importance of the wrapper code.

> May I confirm the class is within the NinjaTrader.NinjaScript.Indicators namespace?

Yes, it is

> Do you have any custom namespaces declared above the class declaration?

Yes, I do, if you mean first in the source file. I have some enums declared in another namespace before the class declaration. The namespace encloses just the enums. It does not enclose the indicator class. I am of the impression that is what NinjaTrader recommends.

> Do you have the indicator open in the NinjaScript Editor and are you compiling from the NinjaScript Editor (and not a 3rd party editor)?

Yes, I am using the NinjaScript editor and compiler. I am neither editing nor compiling in Visual Studio, although I do use that for some debugging.

> May I confirm you are using 8.1.3.0?

Yes, I am using that version.

> May I confirm the indicator is directly inheriting from the : Indicator class?

No, it does not directly inherit -- it has a base class that directly inherits. I have suspected that is what is causing the problem.

I know that the NinjaTrader position is that custom indicators must inherit directly from Indicator, but I do not understand why. Inheritance is such a fundamental part of OOP that it seems like a serious problem to say that indicators cannot use it. I have a fairly large amount of code that is common to all of my indicators, so I do not see a reasonable alternative to using a base class. I don't see how the suggested approach -- using a partial class -- addresses this issue.

Will using a base class cause any problem other than failing to generate the magic code? Is there any reasonable alternative to a base class for a lot of common code -- way too much to include in each indicator, not to mention the maintenance headache that would be?

[NinjaTrader_ChelseaB]

Hello ETFVoyageur,

"Yes, I do, if you mean first in the source file. I have some enums declared in another namespace before the class declaration. The namespace encloses just the enums. It does not enclose the indicator class. I am of the impression that is what NinjaTrader recommends."

Put this custom namespace below the NinjaTrader.NinjaScript.Indicators namespace declaration at the bottom of the file.
(Not within the the Indicators namespace, but below it)

"No, it does not directly inherit -- it has a base class that directly inherits. I have suspected that is what is causing the problem."

This is what is causing the problem. NinjaTrader does not support inheritance with Indicator or Strategy classes.

"I know that the NinjaTrader position is that custom indicators must inherit directly from Indicator, but I do not understand why. Inheritance is such a fundamental part of OOP that it seems like a serious problem to say that indicators cannot use it. "

I can't provide the inner workings of NinjaTrader, but as you can see it prevents NinjaTrader from functioning properly.

Using a partial class allows you to share methods to multiple indicators or strategies, so that you do not have to copy the code into each script individually.
If you are not trying to share methods, what are you trying to do?

"Will using a base class cause any problem other than failing to generate the magic code?"

Yes, this messes up the optimizer in the strategy analyzer, and can prevent indicators from being shown in the strategy builder and market analyzer available lists.

"Is there any reasonable alternative to a base class for a lot of common code -- way too much to include in each indicator, not to mention the maintenance headache that would be?"

We generally recommend a partial class so that you can share methods with multiple indicators or strategies.

The common methods would go in a separate file and by making it a partial class of the Indicator class (which is already a partial class), this makes those methods available to all indicators.
You can then just call the methods from any indicator you want.

[ETFVoyageur]

Thanks for the suggestions. I'll look into them. I'd really rather be operating as NinjaTrader intended.

Is there sample code illustrating the partial class approach?

[NinjaTrader_ChelseaB]

Hello ETFVoyageur,

Below is a link to an example.

https://ninjatrader.com/support/forum/forum/ninjatrader-8/indicator-development/1142334-is-it-possible-to-hide-an-indicator-from-the-list-in-the-indicator-window#post1142340

[ETFVoyageur]

Thank you, Chelsea. You are always very helpful, and I appreciate that. Thank you.

[ETFVoyageur]

Chelsea,

I am looking into partial classes, as you suggested. I'll probably have more questions, but here are some initial questions.

I presume you are suggesting using a partial class to extend the Indicator class. As the comment in your example indicates, namespace pollution will be an issue. ("use long unique method names to avoid conflicting with scripts from other developers"). Am I correct that there is no way to combine a namespace with a partial class to avoid such pollution? If so, then I suppose the best way is to employ a consistent, hopefully unique, prefix for all of your visible names.

It looks to me as if there is a major functional problem with the partial class approach. The partial class cannot override an Indicator virtual function. For example, your earlier suggestion of overriding the Clone() method could not be put into an Indicator partial class. Is that correct, or am I missing something? The inability to override seems like a significant problem with this approach.

That's it for now ... probably more later .....

[ETFVoyageur]

Chelsea,

As a concrete example, my indicator base class overrides the DisplayName property. As far as I know, I cannot do that in an Indictor partial class.

After reading all I can find on the subject, I remain worried about two things:

* Namespace pollution -- probably solvable from a practical point of view by adhering to a unique (hopefully) name prefix.
Ugly, in more than one sense of the word, but does not prevent creating the same functionality one could with a base class.

* Inability to override virtual items from Indicator. I do not know of any solution to that problem. This does inhibit functionality.
For a partial class to be fully acceptable, it needs to have as much functionality as a base class.
I'll be a lot happier with the idea of a partial class when you tell me how it can handle overriding virtual items from Indicator.
Ideas?

[ETFVoyageur]

Chelsea,

After some thought, I have decided that both of my concerns are real, but that I have a good answer for each of them. It took a while, but I now believe I can use a partial class without losing functionality (as compared to using an indicator base class). Thanks for your help.

[ETFVoyageur]

I spoke too soon!

My indicator base class needs a property set in the GUI (the indicators configuration dialog). That cannot (or rather should not) be done in an Indicator partial class because that would make it happen for all indicators. It should happen only for my indicators.

Am I missing something? Any ideas about how to handle that with a partial class?

(Obligatory Gripe: life would be so much simpler if NT would just allow indicators to have base classes rather than requiring us to waste time working around the lack of such a fundamental language construct.)

[NinjaTrader_ChelseaB]

Hello ETFVoyageur,

I will add your vote to request SFT-341 for supporting abstract classes.

Please note, we receive many requests and cannot reasonably implement all requested features or changes. Interest is tracked internally and if enough interest is tracked, it would be weighed against how feasible it would be to make those changes to consider implementing, so we cannot offer an ETA or promise of fulfillment.

When new features are implemented, they will be listed in the Release Notes page of the Help Guide. The ID number may be different than the internal feature request tracking ID, but the description of the feature will let you know if that feature has been implemented.

Release Notes - https://ninjatrader.com/support/help...ease_notes.htm

If your indicator class is a partial class and the custom class is of partial class of the indicator class, it will only be applied to that one indicator.