Is it a bug

[NinjaTrader_JoshP]

Baruch,

As mentioned in my previous post, your coded logic is simply invalid. If you want to know what exactly is happening under the hood you need to add debugging prints into your strategy. For instance, turn TraceOrders on and add prints into OnOrderUpdate(). Then you can very clearly see and understand exactly what your strategy is doing and why.

I have already outlined exactly how to achieve what you want. If you want a historically placed trade to be submitted live, resubmit it in real-time on strategy start up. As it currently stands your code does not resubmit any orders. All it does is keep preexisting orders alive which for sure will not be all of a sudden submitted live since you are using "Wait until flat".

The whole concept of how to program this is very easy. Use liveUntilCancelled instead of trying to keep alive every single OnBarUpdate(). Use IOrder != null checks as outlined in every single IOrder reference sample as part of your entry condition along with that liveUntilCancelled. Use CancelOrder() to cancel the historical order when you start the strategy and determine your Position.MarketPosition is flat. Wait for OnOrderUpdate() to receive the OrderState.Cancelled. Once received and strategy is running real-time, resubmit your order at the same price of the historical one just cancelled.

[Baruch]

Josh,
Thank you for the explanation.
Still I insist that "Wait until Flat" should affect only trades (Position != Flat) there is no state "Flat" for a pending order, but I'm willing to eat this frog and try to maneuver around it.
I issue an order on every bar because the price = EMA[0] changes or may change on every bar. I know that I can issue a "liveUntilCancelled" order and still change its price on every bar. I don't understand whats the big difference, but I'll do it.
Another thing I don't understand is why with my approach

As it currently stands your code does not resubmit any orders. All it does is keep preexisting orders alive

if I recognize the strategy went from historical to live with:
if (!Historical && isHistorical)
{
isHistorical = false;
return;
}
Why the order doesn't expire? The "keep preexisting orders alive" code is not executed on that bar.

Use CancelOrder() to cancel the historical order when you start the strategy

Shouldn't it be: When the strategy goes from historical to live?

Baruch

[NinjaTrader_JoshP]

Baruch,

Very simple, that code has never even been executed yet on strategy start. With CalculateOnBarClose = true, you do not process that code till the minute bar event after strategy start. Then after that to resubmit a new order you wait for another minute bar event afterwards. Effectively a 2min delay.

Another reason you should upgrade to NT7 though, I just tried your strategy on NT7 and guess what, it works exactly the way you desired without any fancy logic we have been discussing for NT6.5. Attached is the NT7 compatible version of your strategy. Works great.

[Baruch]

Josh thanks,
I'll try your code, although I don't see in it any code to cancel the historical order. Are you sure you have "Wait until flat" on NT7.
I can't switch to 7. You can read the whole thread and see why.

Baruch

[NinjaTrader_JoshP]

Yes, it is with WaitUntilFlat. It is important for you to trace out with Print()s and TraceOrders to understand different scenarios your strategy logic runs into as you start the strategy. Depending on the historical data sometimes you don't even have a working historical order and you need to review such debug output to see if such is the case.

We would be happy to look into any reason for why you are not upgrading to NT7, but your post does not inform us in any fashion as to what exactly you are referring to. Please clarify. Thank you.

[Baruch]

Look at this:

http://www.ninjatrader.com/support/forum/showthread.php?t=35144&highlight=debug

http://www.ninjatrader.com/support/forum/showthread.php?t=35935&highlight=debug

[NinjaTrader_JoshP]

As mentioned in the first thread you posted, just pin the tab and it won't slide if you don't like it sliding.

For the second thread, debugging in 6.5 vs 7 for all intents and purposes are the same. Bertrand is already working with that individual to isolate the exact cause on his system/setup.

I do not see how either of these are deal breaker reasons for upgrading to NT7. What I can definitely state is that many of our 3rd party developers and NinjaScript consultants whom I communicate with on a regular basis that do extremely high volumes of work in Visual Studio and NT7 have not reported any such issue on their ends.