When to set iOrder entry object to null?

[Newbie-NT-Scriptor]

I am creating a strategy which utilizes: one entry condition for two separate entry orders; matching manually trailed stops; but different targets. It has one short term target and one runner target, and I need it to be able to re-enter the short term trade if a new signal is triggered while an existing runner is still active.

After many attempts to code this with the basic managed approach, and reading through forum posts, it seems that the advanced managed approach is needed for this type of strategy, is this correct? Or is there a way to do this with basic managed?

For advanced managed, can you please explain why the order object is set to null when the order is filled (reference below), rather than when the position is closed? It seems as though setting it this way would allow re-entry of multiple open positions with the same FromEntry name.

// Resets the entryOrder object to null after the order has been filled
if (execution.Order.OrderState != OrderState.PartFilled)
{
entryOrder = null;
}

Thanks in advance for your help.

[NinjaTrader_Jesse]

Hello Newbie-NT-Scriptor,

Welcome to the NinjaTrader support forum.

When you refer to basic and advanced managed approach are you referring to using the builder vs manually coding? If so yes the idea you described would likely need to be manually coded/it would be easier to manually code.

When using the order objects the entry order is set to null when the execution happens because you can specifically track what order that was. The position event is simply a position change but is not the same as the execution event. The execution event would be more accurate here because that can track partial fills and also if you have multiple quantity positions it would be less complex tracking the fills directly.

It seems as though setting it this way would allow re-entry of multiple open positions with the same FromEntry name.

This would depend on what sample you are looking at, I would need to see more of the context here to know why that was reset from OnExecution and also how that would work in contrast to the remainder of the logic. It is normal practice to use OnExecution to do different tasks related to your order events so depending on what order we are referring to here would determine when the entry order is reset.

I look forward to being of further assistance.

[Newbie-NT-Scriptor]

Hey Jesse,

Thank you for your quick response.

My reference to the terms basic and advanced managed approach came from a Ninjatrader/Big Mike's webinar on ninjascript order management held by NinjaTrader_Josh. In that webinar Josh referred to a "basic managed approach" which involved simple EnterLong, SetStopLoss and SetProfitTarget etc... statements in OnBarUpdate, and compared that to an "advanced managed approach" involving the use of iOrder objects with OnOrderUpdate and OnExecution. I am coding the strategy, and am mostly comfortable with Ninjascript (have coded dozens of custom indi's and several strategies for both 7 and 8) however, the use of order objects is new for me. After a few failed attempts to code my strategy in OnBarUpdate, I think tracking the orders may be necessary.

The code sample I'm starting with is the SampleOnOrderUpdate strategy which I will post below. I think I mostly understand the code and concepts, but as stated before, am having difficulty understanding why the entryOrder object would be set to null when it is filled and the position is still open. Since subsequent calls to onBarUpdate would then find the object null and would attempt to assign a new EnterLong to entryOrder with the same fromEntrySignal name, "MyEntry", as the initial position which may still be open.

Many Thanks,

[NinjaTrader_Jesse]

Hello Newbie-NT-Scriptor,

Thanks for the clarification.

The reasons this does not submit multiple entries is that from OnBarUpdate the entry is only submitted if the entry order object is null, it is immediately assigned so this will prevent multiple entries until that fills. Once it fills it basically won't matter if you call this logic again while you are in the original position. In the situation that another entry is submitted the EntriesPerDirection should take care of that and prevent it.

This is a very simple demonstration of how to make logic based on order events, really it is only to show that concept but is not a specific guideline on how you need to make the rest of your script. In your realworld script it will likely be a lot more complicated depending on what your goals are. Your logic may include additional conditions or other logic to prevent entries from being submitted before you are flat as an example.

The point of this sample is really just to show some order object being used, how they can be assigned or observed.


I look forward to being of further assistance.