Strategy coordination?

[ErikHR1969]

I have 2 strategies I want to run against the SPY. One is an opening gap strategy, so it will place a trade on the first bar of regular trading hours. The other will not place a trade until after 10 am. I do not want the second strategy to place a trade if the opening gap strategy has an open position. How do I coordinate these strategies?

Thanks,
Erik

[NinjaTrader_ChrisL]

Hello Erik, thanks for writing in. Two separate strategies can not communicate with each other. You will need to combine the two strategies into one so the OnBarUpdate logic and trading decisions are all in once place.

Kind regards,

-ChrisL

[QuantKey_Bruce]

Well, yes, combining them into one would be BEST in that you could do lots of things that way. But other approaches for realtime only include you could communicate between them by using something like a static dictionary (or just a static variable if it's simple) or you could monitor the ACCOUNT position rather than the strategy's position.

[ErikHR1969]

Thanks for the tips.

What about if I introduce a class between strategy and my Strategy?

    public class TICKFadeBaseStrategy : Strategy { // General rules, functions and globals
    public class TICKFadeLongStrategy : TICKFadeBaseStrategy { // Long rules and functions
    public class TICKFadeShortStrategy : TICKFadeBaseStrategy { // Short rules and functions
    public class TICKFadeSPYLongStrategy : TICKFadeLongStrategy { // SPY specifics for Longs
    public class TICKFadeSPYShortStrategy : TICKFadeShortStrategy { // SPY specifics for Shorts

This works is it supported?

[NinjaTrader_ChrisL]

Hi Erik, I could not recommend extending the Strategy class as NinjaTrader uses factory methods to create the objects to initialize the class. You should use this idea of a property changed event instead, or just combine the two strategies into one strategy:

https://forum.ninjatrader.com/forum/ninjatrader-8/indicator-development/103089-mysharedmethodsaddonexample

[QuantKey_Bruce]

ErikHR1969 If you search the forum for "abstract base class" or "partial class" you will find that there are ways to do these things but they're not fully supported (at least abstract base classes are not). The "NinjaTrader Way" of doing these things officially and supportable per their comments on the forum is not to use these levels of abstraction but rather to use encapsulation or to put your common code in the AddOn namespace. In your searches for these terms above you'll find some other ways people have gotten things done but you'll receive less help officially if you go those routes as that's off the beaten path and the assumption is if you know enough to build things that way you know enough to do it without official help.

[bltdavid]

The best way to do what you're asking is for Strategy A to create a lock
file -- store this file in 'NinjaTrader 8/tmp' folder, since this folder gets
cleared every time NinjaTrader starts up. This lockfile exists as long
as Strategy A remains in its position.

Strategy B can only enter its own trade if the lockfile does not exist.

I've used this technique, and its works perfectly.

-=o=-

You could make it one-way. Perhaps Strat A never cares about the
lockfile resource itself, it always enters its own trade -- because
what you're trying do is control Strat B from Strat A.

Or you could make it two-way. In this case, which ever Strat has
the lock, ie, which ever Strat created the lockfile, that Strat is the
only Strat allowed to trade. Here the 'permission to submit a trade'
is like a shared resource, being control by the lockfile.

If Strat A is controlling Strat B permission to trade (ie, one-way),
don't let your code in Strat B block/wait until the lock is deleted,
that's not the way to do this. In Strat B, just do a File.Exists() and
if the lock file is found, then Strat B ignores entering it's trade.

-=o=-

I used an abstract base class for common utility methods, that
way both Strats can use the same methods for creating/testing the
lockfile, getting the filename, etc. (For ex, both Strats inherit from
MyStrategyBase, and the abstract class MyStrategyBase inherits
from Strategy, see example here.)

To create the lockfile, I used this code below, which I added to the
abstract base class,

// return true if file created successfully, false if file already exists
protected static bool CreateNewFile(string filnam)
{
    int ErrorCode = 0;

    try {
        using (File.Open(filnam, FileMode.CreateNew))
        {}
    }
    catch (IOException ex) {
        ErrorCode = Marshal.GetHRForException(ex) & 0xFFFF;
    }

    return ErrorCode == 0;
}

Additional lockfile code was built around this key function.

Good luck!

[bltdavid]

That's my NT7 code.

For NT8, you should probably just use ex.HResult,
rather than GetHRForException.

Good reading here and here.

[QuantKey_Bruce]

bltdavid That's a clever and workable solution you have there... But, have you thought about just making a static dictionary somewhere (in the addon namespace, possibly?) so you can stash all sorts of things in it as key-value pairs, like strategy states, and then access them from wherever? That seems like it would have a lot more use cases. And when you restart, you don't have to worry about leftover files hanging around...

[bltdavid]

bltdavid That's a clever and workable solution you have there... But, have you thought about just making a static dictionary somewhere (in the addon namespace, possibly?) so you can stash all sorts of things in it as key-value pairs, like strategy states, and then access them from wherever? That seems like it would have a lot more use cases.

Yes, that could also be a solution -- and I've used it for other things.

The lockfile idea is easier to code and doesn't strictly require a static
Dictionary inside an abstract base class -- the lockfile creation is also
atomic, which can be a good thing for competing strategies vying for
the 'permission to trade resource'. And it can be disabled, say for
Strategy Analyzer backtesting, or Market Replay -- any time your
Strats run independent, the lockfile could could be turned off, since
it is not needed.

But the real reason I kept using it is because I stuff plenty of info
in that lockfile concerning the creator, using key=value pairs, and
I could also delete the lockfile manually in the tmp folder had I some
other reason to do so.

And, the raison d'etre, is the lock file is a text file, and can be
easily examined while everything continues to run.

The lockfile approach has worked well, I found it a bit more KISS
than using a static dictionary in a base/partial class.

In the end, I guess I never found a big enough reason to switch
away from using it -- the lockfile concept ... well, it just works.

And when you restart, you don't have to worry about leftover files hanging around...

But that's just it.

When you restart NT, there are no leftover files hanging around.

The 'tmp' folder is cleared on every restart -- I thought that
was clear from my first paragraph -- my apologies.

If the need arises, the lockfile can be deleted manually, but when
you restart NT, you are absolutely guaranteed a clean slate, every
time.

That's the beauty of using that 'tmp' folder.

[QuantKey_Bruce]

bltdavid All makes sense. Good deal. Thank you for the explanations.