Stop orders not generated after user cancel

[traderpards]

I have developed a strategy for a client and an issue has arisen. It’s never arisen for me because I don’t personally use these types of orders.

I have written and attached here, for demonstration purposes, that issue. Attached is a strategy the will simply place an order on the chart for a long stop market order 15 ticks above the close if the bar closes up and 15 ticks below the close if the bar closes down.

Please run this strategy on a 1 minute chart of a decent volume instrument and observe that the strategy behaves as expected when the user doesn’t touch the orders. For an up bar, a buy-stop order is placed above the close and will stay in force until the bar closes. Then when the next bar closes the strategy will place another trade at the above or below the bar, depending on if the bar closed up or down. It will repeat this, which is expected.

When you are satisfied the strategy is doing what is expected, let’s say you aren’t dealing with such a simplistic strategy but one that is much more complicated with many more criteria for placing an order. Usually you let the order stand – because you’re supposed to trust your strategy - but there may come a time when you don’t like the looks of the setup and you wish to cancel the order. We’re taught that isn’t advised – that you should trust your strategy but let’s also allow user prerogative to cancel the order because after all, the user should be allowed to cancel the order if experience dictates.

With that in mind, after you are satisfied this strategy runs as intended putting a stop market order every other bar or so, as soon is it places the order, cancel the order by clicking the 'x' on the chart, pretending that you are exercising a user inclined prerogative. As a user you are allowed to cancel your orders, after all. When a sell stop is placed cancel it and when the strategy places a buy stop, cancel that one as well.

Now observe that the strategy will never again place another order for any other signal it receives, which in this case is simply whether the bar closes up or down. I have drawn dots where it should have placed a stop market order to illustrate that the strategy is now refusing to place those orders.

Is this expected behavior? If so, how is it that, while the user is allowed to cancel the order if he/she is so inclined, the user isn’t allowed to expect the strategy to place another order at the very next signal or any other signal it ever gets again?

[NinjaTrader_Jim]

Hello traderpards,

Thanks for bringing this up.

I am seeing a difference in behavior between NinjaTrader 7 and NinjaTrader 8, so I don't think we are seeing the intended behavior.

I'll write back when I have further details.

[NinjaTrader_Jim]

Hello traderpards,

After a closer look testing this strategy in NinjaTrader 7 and NinjaTrader 8, it should be possible to have your strategy resubmit entry orders after cancellation if the order entry methods use unique symbol names and you set EntriesPerDirection to Unique Entries.

For example: EnterLongStopMarket( /*0, true, 1,*/ Close[0]+20*TickSize, "LE" + Time[0]);

I had overlooked this prior and this behavior is consistent between both NT7 and NT8.

Please let me know if I can be of further help.

[traderpards]

Thanks Jim... just now getting around to trying your idea, which is to append the time to the entry name in order to make it a unique name, and of course setting EntryHandling = EntryHandling.UniqueEntries.

It doesn't work. On the second entry after cancelling the first, EnterLongStopMarket() still returns null. "It should be possible..."

I agree. It should be possible.

[NinjaTrader_Jim]

Hello traderpards,

I revisited this and set up the test script to show the behavior you are looking for.

Demo: https://www.screencast.com/t/IG8EuAMmrug

If something is still sticking out, please let me know and we can take another look.

[traderpards]

Hello traderpards,

I revisited this and set up the test script to show the behavior you are looking for.

Demo: https://www.screencast.com/t/IG8EuAMmrug

If something is still sticking out, please let me know and we can take another look.

That's exactly the behavior I'm looking for. I'll play around with it until I get it working.

Thank you!!

[traderpards]

I must be missing something... When I generate an order almost like you are, I get the time stamp that is 45 minutes ago. You can see in the screen shot that it's 12:30 (actually it's the 12:25 bar) but the time the system is recording is 11:45. I don't understand that....

When I say "almost like you are," I'm referencing a 3-second data series and tying that to the entry, like so:

 EnterShortStopMarket(0, true, quantity, currentPrice, "SE" + Times[1][0] );

And then OnOrderUpdate I have:

            if (EntryShort != null
                && EntryShort == order)
            {
                if (orderState == OrderState.Cancelled
                    && Position.MarketPosition == MarketPosition.Flat)
                {
                    EntryShort = null;
                }
            }
            else if( order.OrderState == OrderState.Accepted
                     && order.Name.Substring(0,2) == "SE" )
            {
                EntryShort = order;
            }
{

This works just like yours did in the test app so I went with it. I just don't understand why the time stamp isn't 3 seconds ago since it's a 3-second series, like I would expect. (Note: the chart is a 5 minute bar so even if it stamps itself with the chart bar, shouldn't it say 12:25?)

Can you help me understand why the time stamp printed 45 minutes before instead of something more recent?

Thanks!

[NinjaTrader_Jim]

Hello traderpards,

Thanks for the reply.

The Signal name for the order would be the "SE" + Times[][] used in the order submission.

Could you share with me a screenshot of the output window with TraceOrders enabled and a print of Times[1][0] next to the order submission method so we can verify the time used for the signal name?

I look forward to being of further assistance.

[traderpards]

The time OnOrderUpdate = is correct.
The time "Right before EnterLongStopMarket" is not. (Assuming they both should be the current time.)

That's why I used Substr() to match the order name to assign order to EntryLong.

[NinjaTrader_Jim]

Hello traderpards,

Thanks for your reply.

The output isn't exactly clear to me where the prints were made and the syntax for what you are printing. For example, printing Times[][] directly from OnOrderUpdate() without accessing the Times with GetValueAt() would not be a guaranteed reference.

We would really want to see:

• The Times[][] value used in the order method printed in OnBarUpdate() just before the order method
• The Signal Name of the order in OnOrderUpdate() or the Signal Name as noted by Trace Orders

If you would like to submit a new version of the code with exactly what you are looking at, I can create a another demonstration explaining the output. If there are some clear steps that you would like me to take that show a difference in behavior, please let me know so we can review that particular case.

I'm happy to be of any further assistance.