how to create my base indicator without showing in indicators list

[ttodua]

Unprecedent event. one request from 30 of mine other requests, after 3 years and multiple votes, seems to be implemented.

[NinjaTrader_ChelseaB]

Hello Community,

As it does not appear to have been mentioned in this thread so far, partial classes is likely the way to go.

Inheritance is not supported with NinjaScript Indicators or Strategies. Instead, we recommend you add methods or custom properties as a partial class to either the Indicator class or to a specific indicator.

Below is a link to an example.
https://ninjatrader.com/support/foru...ow#post1142340

When it comes to feature requests. Many feature requests are implemented when a new major version is released, such as the over 500 user driven enhancements implemented when NinjaTrader 8 was first released.

[bltdavid]

Yes ... and ... SFT 15265?

What is this for?

[bltdavid]

Inheritance is not supported with NinjaScript Indicators or Strategies.

You say 'not supported' ... like that feature doesn't work.

The concept is universal to C# and works just fine. There
are some caveats to watch out for, due to NinjaScript editor
clumsiness with abstract classes. Like I said, the NinjaScript
compiler is the only blocker.

What you really mean to say is NT Support will not help
any NT developer with understanding this -- which is a huge
shame because the technique is very elegant and solves
many problems -- it's the C# way to think about base
classes and inheritance, I'm dumbfounded why NT will
not embrace this as a development technique.

It's like because no one there has any kind of knowledge
how it could be useful, y'all simply have decided to warn
everyone its 'not supported' which tends to scare people,
driving them away from using an abstract classe -- when,
in fact, it's an absolutely fantastic solution, one of the
better techniques to organize one's growing personal
library of NinjaScript code.

It's actually the best solution of them all!

NT's continued 'not supported' stance does a grave
disservice to your development community, esp the
newbies just starting their journey into the wonderful
world of C# and NinjaScript coding.

Just my 2˘.

[ttodua]

bltdavid absolutely agree.

[NinjaTrader_Emily]

Could someone at NT Support expand/explain the release note
as seen in the attached screenshot?

That is, please explain significance of SFT 15265 in 8.0.27.0,
"Browsable attribute on indicator having class scope"

To what does this feature/fix refer to?
What problem/feature/fix is being resolved?

Does it have anything to do with this forum topic?
Has any documentation been updated to reflect this change?

Hello bltdavid,

Thank you for your patience.

Issue # 15265 should apply to Charts, Strategy Analyzer, Market Analyzer, SuperDOM Column, and Alerts condition builder class listings. This will allow you to set an indicator to be browsable or to be hidden from the property grid listing of available indicators in order to avoid confusion under certain circumstances as well as to optimize the performance when first loading the indicators prior to the indicators being cached.

In response to your post # 19 when we say "not supported" that is because inheritance is not documented and we are aware of certain limitations specifically for indicators and strategies. The code that NinjaTrader uses as wrappers for caching, cloning, and generating overload parameters as well as how NinjaTrader generates instances of strategies for optimizations are not able to properly handle inheritance. I suspect that using inheritance with your own custom add-on window or items in the add-on class would work as expected, although these items are still undocumented in the NinjaTrader help guide - NinjaTrader-specific support is limited when it comes to inheritance as this is a broader C# concept and we do not offer hands-on C# education services. We do know that we are not able to offer support regarding inheritance specifically with indicators and strategies due to the reasons I mentioned. We know there would be an issue when attempting to do this, which is why it is officially not supported. Our development team does have it under consideration and our team is tracking demand.

I hope this information helps to clarify. Please let us know if we may be of further assistance.

[ttodua]

NinjaTrader_Emily it would have been nice, if your dev team shared even some hints/notes, of what you/they mean "some issues". for example, dev.team knows that

> when using inheritance, in NT's window X it won't show Y thing or Z functionality will not work

so, we would have some insights about "what problems does inheritance cause in NT", as opposed to the generic knowledge that knowing that "inheritance is not recommended in NT, because it will cause some unexpected bugs"...

that's what I would mean in "basic support" to give the amatuer NT programmers.

[NinjaTrader_Emily]

Hello ttodua,

Thank you for your reply.

I understand it can be frustrating to not have specific details about why and in which specific cases inheritance won't work. Our understanding from a support perspective is also very generic and the workaround we are able to provide to our clients is to use partial classes as my colleague Chelsea explained in his earlier post in this thread:

https://ninjatrader.com/support/forum/forum/ninjatrader-8/indicator-development/1049855-how-to-create-my-base-indicator-without-showing-in-indicators-list?p=1226825#post1226825

Although the development team has a deeper understanding of what is going on behind the scenes, one of the reasons they have not provided more hints or notes is that it would get into what is going on "under the hood" in NinjaTrader and that has to do with proprietary information and code that is not available to the public. One example I referenced is the wrappers that are added for indicators; you may see these wrappers at the bottom of an indicator's script in the "#region NinjaScript generated code. Neither change nor remove." section of the script. When it comes to strategy instances and optimizations, this information is not public knowledge. It is not documented in the help guide and I suspect the development team does not have plans to release any additional details about why they don't work with inheritance. Even if more specific details were available for us to provide, this would not change the current stance that partial classes should be used as a workaround and we will continue to track interest regarding inheritance and the potential to add additional support for it in the future.

I sincerely appreciate your patience and I hope you understand that we are not trying to leave anyone in the dark, including amateur programmers. Our team supports the platform with the information and tools available to us and we do our best to offer solutions on how to use NinjaScript in order to get the desired outcome, whether the answer is confirming how to do something or offering a different approach that achieves the same or similar results.

Please don't hesitate to reach out with any additional questions or concerns.

[ttodua]

partial classes are not (at least in my case), and to be honest, I have hard time to think of what could be proprietary in saying small artefacts of the side-effects, which might be caused by inheritance. but as it's your politic, and you are not fixing it yet, I understand. thanks for efforts, keep going.

[StoneMan78]

I'm curious if there are any updates to add to this topic given the release of 8.1. I've been trying to implement inheritance to some recent indicators myself and ran into a wall (hence why I'm here). I'm curious what the most up to date workaround for this limitation is.

[NinjaTrader_Emily]

I'm curious if there are any updates to add to this topic given the release of 8.1. I've been trying to implement inheritance to some recent indicators myself and ran into a wall (hence why I'm here). I'm curious what the most up to date workaround for this limitation is.

Hello StoneMan78,

Thank you for your note.

The fixes and features implemented for version 8.1 may be found in the release notes here:

https://ninjatrader.com/support/helpGuides/nt8/8_1_1_1.htm

That said, partial classes are still the way to go when it comes to inheritance as mentioned in post number 17 higher up on this page:

https://forum.ninjatrader.com/forum/ninjatrader-8/indicator-development/1049855-how-to-create-my-base-indicator-without-showing-in-indicators-list?p=1226825#post1226825

We also have some basic information and examples in the help guide. You may Ctrl + F to find "Partial Classes" on this page to find the relevant information:

https://ninjatrader.com/support/helpGuides/nt8/index.html?code_breaking_changes.htm#ImplementationChangesOverview

What is noted in the best practices page regarding NinjaScript wrapper limitations is still in effect, even on the latest release:

https://ninjatrader.com/support/helpGuides/nt8/index.html?ninjascript_best_practices.htm#MiscellaneousPractices

Wrappers cannot be generated automatically for partial and abstract classes

This is why the previous link mentions that partial classes are best built manually and saved in the NinjaTrader 8\bin\Custom\AddOns folder.

Warning: If a partial class is saved in one of the folders used for specific NinjaScript objects other than AddOns (e.g., Indicators folder), auto-generated NinjaScript code may be appended to the end of the class by the NinjaScript Editor when compiled, which will cause a compilation error. Saving these files in the AddOns folder will ensure they are still accessible and will not generate code which may be cause conflicts.

Thank you for using NinjaTrader.

[bltdavid]

Let's stop the nonsense.

Partial classes are not 'the way to go'.

Partial classes are one way to go and they have limitations,
esp when compared to the beauty and elegance of an abstract
base class.

If you find the auto-generated code showing up at the bottom
of your abstract base class, then by all means, move it to the
AddOns folder -- just like you would do for a partial class.

NT Support continually denies that an abstract base class has
any worth -- yet C# is an object-oriented language and is all
about inheritance. Guess what? An abstract base class is
absolutely and completely supported by C# and the NinjaScript
framework just fine. Full-stop. End of story.

The NinjaScript compiler is the only blocker here. It's pretty naive
and blindly emits magic code for an abstract base class -- but
one solution to this problem is to move the file to the AddOns
folder -- gee, this is the same suggestion NT support makes
for partial classes.

NT Support fails to prioritize any time to educate themselves
about abstract base classes. Their fetish is simple -- they want
you to use partial classes and, for them, there is no substitute.

Hey Support --
Not even a worthy discussion of why an abstract base class
is bad, not even one example of why an abstract base class
is bad? Why the pathetic support ethos to keep suppressing
abstract base classes? It's a ridiculous mandate throughout
support that each and every support engineer must continue
to deny the usefulness of an abstract base class. I just don't
understand it. Where is the initiative for one of you NT support
engineers to investigate abstract base classes and make
some positive comments about their usefulness?

Hey Support --
You seem to harp about magic code issues with abstract base
classes, but then admit to that same problem with partial classes
and suggest relocation to the AddOns folder. Gee, this exact
same suggestion solves the issue you keep harping about with
abstract base classes.

Remember --
'Not supported' does not mean 'does not work'.
'Not supported' means 'they won't help you on that topic'.
A abstract base class works just fine, just like a partial class
works just fine, but an abstract base class is a much better
solution and has advantages over the partial class approach.

Why is an 'abstract base class' unsupported?
I dunno, I have never seen a decent explanation.

What galls me is that NT support continues to suggest and imply
and cajole users into thinking that partial classes are the 'way to
go' -- which is a load of crap. That's one way, not the way.

Use an abstract base class.
Ignore NT support on this matter.
You'll be fine.

[bltdavid]

Wrappers cannot be generated automatically for partial and abstract classes

I know the help guide says this, as Emily points out, but it is blatantly false.

Wrappers are generated automatically for partial and abstract classes.

In fact, that's the entire problem!

What is the issue?
The NinjaScript compiler is unable to recognize partial and abstract classes
and blindly generates the magic wrapper code at the bottom of the file.

Why it's worded that way in the help guide is beyond me -- makes no sense.

This is why the previous link mentions that partial classes are best built manually and saved in the NinjaTrader 8\bin\Custom\AddOns folder.

Ok, so magic code gets added to the bottom of your partial or abstract class.
It's crap, probably causes compiler errors, and you don't want it there.
What can you do?

What Emily forgot to say is that partial classes and abstract base classes
should be saved in the AddOns folder.

See, Emily? I fixed it for ya.

-=o=-

Btw, did anyone catch that?
The help guide mentions abstract classes in the same sentence as partial
classes ... yeah, I know, stop the presses ...

But, has anyone noticed?
The folks in NT Support never want to mention abstract classes.
Now, why is that?

-=o=-

Partial classes are not an intrinsic feature of NinjaScript. They are
a fundamental part of the C# language, just like abstract classes.

Partial classes are not a NinjaScript thing, they are a C# thing, the
exact same as abstract classes.

Continued 'support' for partial classes probably comes from legacy
NT7, where the standard predefined file 'UserDefinedMethods.cs'
was provided as a way to augment the Indicator and Strategy
classes, because that file was pre-populated into both of those
folders on NT7.

NT8 has done away with this file, but they resurrected the 'partial
class' concept when it was shown to be extremely usefulness here.

But, for some reason, any mention of abstract classes is avoided
like the plague.

I ask again, why is that?

NT Support spends way too much effort explaining their twisted
reasoning that partial classes are 'in' and abstract classes are
'out' -- is that a management edict?

Emily/Chelsea, I implore you, please study up on the concept and
provide the same level of simple basic support for abstract classes
as you do for partial classes.

You would be doing a great service for the entire community.

[QuantKey_Bruce]

But, for some reason, any mention of abstract classes is avoided
like the plague.

I ask again, why is that?

I don't see either why this couldn't be done. With a little developer attention to the NinjaScript editor so that the decoration it adds to the indicators "understands" abstract classes (and ignores them) this wouldn't even be a thing.

[jeronymite]

bltdavid on target! QuantKey_Bruce in the right direction.

The "NinjaScript Editor" is really just the Actipro Syntax Editor. This post has more to say on the matter, as well as links to even more to say on the matter!

Summary: it's old, it's bug-ridden, it has needed to be brought up to the latest version for years.

And while we're at it, so do C# and .NET (yes, that old chestnut, again!). Also, recognise that SharpDX is no longer supported, as of almost exactly 4 years ago, to be precise; but there are alternatives.

The Desktop platform wisely incorporates some very useful third-party products that reduce the need for NinjaTrader to "re-invent the wheel". Sadly though, NinjaTrader has not kept those products up-to-date, and seems unwilling to do that, despite a cacophony of requests from its often highly-knowledgeable user community. This means, as I have spoken of in detail elsewhere (see C#/.NET post linked above), that the platform is using many third-party products that have been obsolete for years, even though up-to-date versions (or good, compatible alternatives) exist for them.

Waaaaaay past time to rectify the situation!

Thanks.