The managed approach behind ExitLongStopMarket etc. is looking at old data

[digibob]

Hi. I have a strategy that runs on daily time frame. I added 1-minute historical data for the sole purpose of being able to "buy on close" in backtesting. Sort of. I place the order at 15:59 EST.

Once the order has executed, in OnExcutionUpdate I place a stop order using ExitLongStopMarket.

On gap-up days, this may result in an error saying "A Sell stop order has been ignored since the stop price is greater than or equal to the close price of the current bar."

What happens is, the message says "current bar" but the price being checked against is in fact yesterday's close, because today's bar has not closed yet.

Meanwhile however, another time frame does exist and is used by the strategy, dear protecting-logic-behind-the-scenes, could you not recognize the greater granularity and consider the more recent price before you cancel my order based on a figure from yesterday that is irrelevant now?

What is one supposed to do, use unmanaged approach? I rather not.

[digibob]

Update: current workaround: I use conditional code for historical and realtime states in both OnBarUpdate and OnExecutionUpdate. In realtime the stop order call
takes place in OnExecutionUpdate when the entry is filled. In historical there is only a flag set in OnExecutionUpdate that allows a stop order call to take place in
OnBarUpdate in the last 1-minute bar of the session, after the daily bar has closed. To know which bar is the last of the session I had to use SessionIterator and a
time check, because Bars.IsLastBarOfSession apparently doesn't work with Calculate set to OnPriceChange or OnEachTick.

It is not an elegant solution. It messes up the code and more important, it relies on the entry taking place 1 minute before the end of the session. If the entry was
earlier in the day, several hours would go by before placing the stop order, that's not good.

Bottom line I think there is room to make the internal stop order validation smarter, to spare the need for such shenanigan in backtest code when trying to accomplish something that is quite trivial: placing a stop order midday when the primary time frame is daily. The validation should use the secondary, lower time frame that was added to the strategy.

Thank you.

[NinjaTrader_Kate]

Hello digibob,

Thank you for your post.

I believe this is occurring because while you're submitting your initial order on the secondary time frame, I suspect you are not submitting the stop to the secondary series. Rather, I think the stop is being submitted to the primary series. I've attached two demo scripts that you can backtest and look at in order to see the difference. TestGapUp will submit the stop to the primary (Daily) bar, while TestGapUp2 will submit the stop to the secondary minute bar.

I was able to get the error you've been receiving by backtesting in the Strategy Analyzer using the following settings with TestGapUp, but not with TestGapUp2:



If you open the two strategies in the NinjaScript Editor, the only difference you'll find is on line 117:

stopOrder = ExitLongStopMarket(0, true, execution.Order.Filled, execution.Order.AverageFillPrice - 50 * TickSize, "MyStop", "MyEntry"); in TestGapUp - the 0 here signifies it will submit to the primary time frame.

stopOrder = ExitLongStopMarket(1, true, execution.Order.Filled, execution.Order.AverageFillPrice - 50 * TickSize, "MyStop", "MyEntry"); in TestGapUp2 - the 1 means it will submit to the secondary series.

I'd recommend taking a look at how you're placing that stop order and try the syntax above. Do you still get the same error?

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

[digibob]

Hi Kate. Spot on. All I had to do originally was change that 0 to 1. Clearly some NT users are not the brightest, and evidently the internal order handling is smart enough, my apologies.

Great help. Many thanks!