Looking to program a central functionality

[WHICKED]

I am looking to make a functionality where in it will be a piece of code that is centrally located that all the indicators can communicate to. This functionality will be communication to outside data sources, but any indicator can reference it. I am not looking for the communication path etc, I am looking to see if the functionality of a central location etc for any indicator to access.

The things that are needed for this are:
- Hidden from Indicator and Strategies lists
- Located in NinjaTrader directories
- Ability to be compiled and exported via the NinjaTrader export utility

Is this possible in NinjaTrader? If there is documentation on this 'type' of functionality, it would be appreciated.

[NinjaTrader_Kate]

Hello WHICKED,

Thank you for your post.

You could create user defined methods in a partial class that any indicator can access. I'd advise taking a look at our help guide section on this here in the section on Partial Classes:

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

This prior thread from the forums may be helpful and demonstrates how to set this up so it would not show in the indicators list:

https://ninjatrader.com/support/forum/forum/ninjatrader-8/indicator-development/1055128-creating-user-defined-methods?p=1055186#post1055186

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

[WHICKED]

Followup question. Is there a way to wait to load a indicator until a a method that is contained in that partial class implementation has completed?

[bltdavid]

You can also try using an abstract base class.

[WHICKED]

Thanks, now is there a way to pause the startup of a indicator in say the State.DataLoaded etc that will call to this partial/abstract class and wait until it completes that call.

[bltdavid]

The answer is, yes, of course, there is a way.

It's called sequential code execution, which is a fundamental part of the
principles of computer programming -- the entire foundation of digital
computing depends upon this basic concept.

The sequential nature of code execution still holds -- even with event
driven programming, even inside State.DataLoaded -- so it's highly
likely whatever concerns or worries you have are completely unfounded.

Beg pardon, but I can tell you didn't study the example code very well.
If you had, you would have seen some function calls into the abstract
base class from OnStateChange -- and, if you had compiled and
executed that code, you'd see that those function calls work just fine.

-=o=-

Here I begin my rant. Stand back and watch the flood gates open.

NinjaTrader doesn't talk about or provide support that includes the
use of abstract base classes. They insist that unknown and mysterious
'issues' are possible if you use them, but they have never quite defined or
explained these issues in detail, nor have they ever bothered to study
the abstract base class concept and provide official guidance and
support to work around these issues.

An abstract base class is an advanced concept, just like partial classes,
but the abstract base class concept receives no attention from Support,
despite the tremendous appeal of the problems they help to solve.

That is, not a week goes by that someone doesn't post a question on
how to better organize their growing common code so that don't have to
duplicate their common code inside each new indicator or strategy. Every
time, Support will dutifully trot out their official response with examples of
using partial classes -- purposefully ignored the benefits of abstract base
classes, which is an extremely useful response to the same question.

For some reason, there are 'issues' that have frightened NinjaTrader
Support from ever investigating abstract base classes further. Asking
directly about the support of abstract base class concepts and/or the
'issues' is a deep dark black hole strewn with evasive non-answers.

(Btw, partial classes also have 'issues', but these are conveniently
glossed over or ignored.)

My point is, abstract base classes are fundamental principles of
object oriented programming, and the C# language supports the
concept just fine -- just like it does for partial classes. That is, I'm
saying any impediments to their use are artificial and solely due to
NinjaTrader's own making, or lack of understanding, or both.

Abstract base classes are incredibly powerful and provide tremendous
benefits when properly designed and implemented by a skilled C#
programmer.

Ok, end of rant, now back to my normal helpful self.

Download and study the example code I provided. It's a simple
example and gets you started by seeing the concepts in action.

And, yes, those concepts work just fine inside OnStateChange.

[WHICKED]

I actually did read and understand your code. Basically you are setting data on the onstage change for your strategy.

quick and easy implementation and I have done the same.

a more specific question. As a call to a method could be synchronous.

[bltdavid]

Support will have to confirm, but I'm pretty sure calls made to your
OnStateChange are normal synchronous methods calls.

Besides, think about this: your OnBarUpdate hasn't been called yet.

That is, when OnStateChange is called with State.DataLoaded, no bars
have been processed yet, so your code has done zero work of any kind
that would cause the 'asynchronous interference' you're concerned about.
How can it? No OnBarUpdate processing has occurred yet.

Use of an abstract base class, in and of itself, does not specify or dictate
that method calls into that base class are asynchronous.

Inside the NinjaTrader.exe multi-threaded design,
Some callbacks only happen on certain threads, and thus certain things
can be executing 'simultaenously' -- which means you might need a lock
around critical sections that access global static data in that abstract
base class.

But, let's be clear, doing that is a different technique and done for different
reasons -- an abstract base class is a non-player in the designation of
a critical section of code.

Critical sections can be placed most anywhere, including inside an
abstract base class -- they are completely independent concepts.

[bltdavid]

If your OnStateChange makes asynchronous calls to some method,
then, well ... ok ...whatever, that's fine, too -- but the abstract base
class is not directly involved if you choose to do that.

Sure, that asynchronous method you're calling could be located inside
your abstract base class, but that's just coincidental.