how to create my base indicator without showing in indicators list

[ttodua]

I had similar question/feature request a long ago, but as none of the feature requests from programmers are never implemented, i ask other members if anyone knows a solution.

I have my custom base indicator skeleton:

namespace NinjaTrader.NinjaScript.Indicators
{
    public class MyBaseIndi :  Indicator
    {

        //here I have only several my C# generic methods, which I reuse in all indis
    }

}

and have all other indicators based/inherited from to that:

namespace NinjaTrader.NinjaScript.Indicators
{
    public class MyIndicator1 :  MyBaseIndi
    {


    }

}

However, in indicators list (when I click on CHart>Indicators) "MyBaseIndi" shows up too. How can I hide that in the list?

[NinjaTrader_Jesse]

Hello TazoTodua ,

Thank you for the post.

There is currently no concept to hide an indicator completely, any class which inherits from indicator would be an indicator and would be listed. I would need to put in a feature request here for the ability to hide an indicator. The tracking id for that request is: SFT-3412

I look forward to being of further assistance.

[bltdavid]

What if your base indicator class is abstract, did you try that?

[ttodua]

Jesse, there is no point creating feature requests, you know it. (even thought that is extremally simple, just implementing in NT a new property "HideThisIndicatorInList" in "State.SetDefaults" or whatever, and then the GUI shouldnt show indicator which has that property set to false).

so, this was not a feature request, just i asked again if there is some new knowledge to do what i asked. Many thanks Jesse !

(btw, i have created a feature request for that already years ago for that, however as feature requests ID's are not public, i dont remember).



bltdavid

o_O

THANK YOU ! !

can't believe, that worked...

[martyn73]

Believe here is your previous request: https://ninjatrader.com/support/foru...icator-in-list

I'm also looking for a solution to this.

[bltdavid]

can't believe, that worked...

Abstract classes cannot be instantiated into objects, but can only be inherited from (aka, only useful as base classes).

The entire plugin architecture of NinjaTrader (both Indicator and Strategy are just "plugins") heavily depends upon
some advanced capabilities of .NET known as Reflection.

Reflection allows you to examine compiled .NET code, inspecting it for types, classes, properties, etc.

I presume 'abstract' works because NT engineers use Reflection. And, upon finding the abstract class in the
Assembly, they skip over it because they know this class cannot possibly be a 'plugin' class -- because the
abstract class cannot be instantiated as an object, it cannot be a plugin class -- so they know to ignore it.

Good reading here:
https://softwareengineering.stackexc...-or-interfaces

[ttodua]

bltdavid hank you very much for that information ! i didn't know that

[dween]

It turns out that making the base class an ABC doesn't help - the Editor still insists on putting the automatically generated code at the end of a class declared abstract, and then that code gets a compilation error, "Cannot create an instance of the abstract class" which is correct - we don't want to create an instance...

It turns out that as developers, using a base class lets us pull code out of classes into a common defined (base) class ("only define it once").

Ninjascript could implement it's "plugin" mandate, i.e. it could give itself the ability to detect Indicators automatically, if it instead had required that a class implement an interface, rather than extend a base class.

I imagine that would be a rather huge architectural change, but - could someone submit a change request for that?

It would free developers to implement our classes in reasonable ways, but give NT the ability to identify an indicator as such.

[NinjaTrader_Emily]

Hello dween,

Thank you for your note and the suggestions.

Abstract classes are not supported in NinjaScript. I have added your votes to SFT-3412 (a request for a property to restrict specific windows a NinjaScript object can be applied to) and SFT-3027 (a request for an 'IsCodeOnly' property for indicators). Please refer to these request IDs if you have any questions, and keep an eye out in the Release Notes to see if they have been implemented:

https://ninjatrader.com/support/helpGuides/nt8/release_notes.htm

Please let us know if we may be of further assistance.

[bltdavid]

As far as I know,
the NinjaScript Editor is the only blocker to using abstract base classes.

The C# language itself is not the issue.

Solutions available here and here.

[bltdavid]

Abstract classes are not supported in NinjaScript.

This blanket statement benefits from further explanation.

Abstract classes are supported by the C# language just fine.
Abstract classes are supported by the NinjaScript Framework just fine.

Abstract classes are not recognized by the NinjaScript compiler.
The NinjaScript compiler is the only problem.

Until NT fixes the NinjaScript compiler's inability to recognize abstract
classes (and therefore avoid appending generated code) the best
solutions are available above in my previous post.

Ergo,
Until NT fixes the NinjaScript compiler, NT support keeps producing the
blanket statement that abstract classes are 'not supported' -- which
really just means they refuse to help developers on this topic.

In summary, with regard to abstract classes, 'not supported' does
not mean 'does not work' - it means you, the NinjaScript developer,
will get no help from NT support.

Just my 2˘.

[bltdavid]

For new readers, a complete abstract base class example is here.

The example is for a strategy, but the C# concepts and the separation
of NinjaScript code into multiple files should work for indicators just fine.

[ttodua]

bltdavid thanks for your inputs! good findings, I was using your way too in the past (avoiding opening the abstract holder file in NT editor). Mojo's trick is also funny, but not much reliable. the third option, which seems reliable and more stable, is to place the abstract class file under `AddOns` or other folder, where, even if opened in NT editor, the NT generated codes weren't added as I remember.

[bltdavid]

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?

[bltdavid]

I mean, there have been no updates to the BrowsableAttribute documentation.
(at least not yet)

Hmm ... but still ...
could this SFT be the fix that exactly addresses this forum topic?

It looks very promising ... my fingers are crossed!