order management

[koganam]

...There is no limitation that prevents cancelling a working order and submitting a reveral order within the same bar. This may be true historically but no as far as operation of a live strategy. In fact, I sent to you a strategy that does exactly this and works as efficiently as possible to send the reversal order as soon as the exit order is cancelled. It also sounds like you have coded your own solution to this which is great.

On 04-11-2011, I wrote in this thread: http://www.ninjatrader.com/support/f...48&postcount=4, the following:

" ... After turning on TraceOrders, I think I have began to understand why NinjaTrader does not allow an Exit() immediately followed by a reverse entry on the same tick, which essentially is what is happening if CalculateOnBarClose is true." (new emphasis added)

I think we may have gotten lost in the verbiage, and I accept the blame. It is a simple issue of not always stating all the conditions because I made the assumption that every good trader that I know assumes as near gospel: an unclosed candle means nothing; it only talks when it is closed. Therefore, I always had the unstated assumption that CalculateOnBarClose is true unless I say otherwise. Indeed so does NT, as that is the default for CalculateOnBarClose.

So now as stated above, here is the issue again.

1. CalculateOnBarClose is true. (the NT default)
2. Position has a protective stop.

Is it or is it not possible to reverse on a single candle?

The solution that you sent me explicitly makes COBC false ab initio. Of course that will work provided one is willing to make the computing resources available. Indeed my own solution, among other things, itself turns COBC temporarily false, then places the reverse order, then turns COBC back to true. (There are other issues that also need handling, to ensure consistency and safety, so there is more to it than just that).

So, I guess as I have not consistently stated the "CalculateOnBarClose = true" condition when I made my statements, my statements are not completely correct.

The internal order handling rules are not a limitation but are part of the design of our managed framework. We recognize some would prefer a different handling and provide an option for that.

Something being a deliberate design decision does not mean that it is not a limitation. A limitation can be a deliberate part of a design: there is nothing which makes them mutually exclusive. Actually as no design does everything, all designs have limitations. You seem to be objecting to the particular word "limitations". It is just a description: a "limitation" does not necessarily have negative connotations.

Design:
(noun) a specification of an object, manifested by an agent, intended to accomplish goals, in a particular environment, using a set of primitive components, satisfying a set of requirements, subject to constraints;
(verb, transitive) to create a design, in an environment (where the designer operates)

[NinjaTrader_RyanM1]

It's still possible to make a reversal while you have protective stops, even when CalculateOnBarClose = true. The key idea is using OnOrderUpdate for monitoring changes in order states. You're checking that it is cancelled there, and do not have to wait until the next bar to verify this. It's also possible to submit the reversal order within OnOrderUpdate after checking for this state change, so there should not be any sort of 1 bar delay.

OnBarUpdate() is only one part of NT's framework and you can take advantage of the other handlers to check conditions and process actions intrabar, even when COBC = true.

If you want to change the strategy I sent to use COBC = true, this is possible but will need to change the submission of the initial exit order to use the principles in the following sample: Otherwise there is a delay in the exit order submission:

http://www.ninjatrader.com/support/forum/showthread.php?t=7499

[koganam]

It's still possible to make a reversal while you have protective stops, even when CalculateOnBarClose = true. The key idea is using OnOrderUpdate for monitoring changes in order states. You're checking that it is cancelled there, and do not have to wait until the next bar to verify this. It's also possible to submit the reversal order within OnOrderUpdate after checking for this state change, so there should not be any sort of 1 bar delay.

OnBarUpdate() is only one part of NT's framework and you can take advantage of the other handlers to check conditions and process actions intrabar, even when COBC = true.

If you want to change the strategy I sent to use COBC = true, this is possible but will need to change the submission of the initial exit order to use the principles in the following sample: Otherwise there is a delay in the exit order submission:
http://www.ninjatrader.com/support/f...ead.php?t=7499

Am I wrong, but I seem to remember that protective orders (as in those made with SetStopLoss()), do not have IOrders. With no associated IOrder, how can you use OnOrderUpdate()?

[NinjaTrader_RyanM1]

That's correct. Set statements don't fit in anywhere here. They are convenient but do not offer the level of control needed for this scenario - they can't be cancelled. You can monitor for order state changes with set statements though.

Equivalent protective orders can be placed using:
ExitLongStop()
ExitLongLimit()
ExitShortStop()
ExitShortLimit()

You can submit these as liveUntilCancelled = true and they'll will function similar to orders submitted with set statements. The other distinction is that they're not automatically submitted upon entry execution, like Set orders are. You would need to use the reference sample linked in previous post to get this equivalent functionality.

[nightriderx]

and on a completely different topic...what are your thoughts of starting a new thread (as in process) for OnOrderUpdate() within the strategy?

[NinjaTrader_RyanM1]

nightrider,

There should be only one OnOrderUpdate() per strategy.

[koganam]

and on a completely different topic...what are your thoughts of starting a new thread (as in process) for OnOrderUpdate() within the strategy?

I would, and I do not even mind sharing what I did. The only problem is that the solution that I coded is pretty convoluted, and I have not really had the time to test it for safety, and to be sure that it will act correctly in all situations, so I am reluctant to even start down that road publicly. I have been caught up in a few too many other things that were amenable to quick solutions, and I am focusing more right now on getting my enterprise off the ground. Once that is done, I might come back to code-testing. It is not the writing that takes time: it is always the testing, because there are always bugs, even in the simplest of multi-line code.

[koganam]

That's correct. Set statements don't fit in anywhere here. They are convenient but do not offer the level of control needed for this scenario - they can't be cancelled. You can monitor for order state changes with set statements though.

Equivalent protective orders can be placed using:
ExitLongStop()
ExitLongLimit()
ExitShortStop()
ExitShortLimit()

You can submit these as liveUntilCancelled = true and they'll will function similar to orders submitted with set statements. The other distinction is that they're not automatically submitted upon entry execution, like Set orders are. You would need to use the reference sample linked in previous post to get this equivalent functionality.

By the time that we get into all that, most of the simplicity of a managed approach has been lost anyway, so one might as well use an unmanaged approach. I really do prefer to have NT managing the position, as NT has already worked out many of the rules to keep the situation safe if glitches occur, but it is looking more and more as if I have to forget about the managed approach completely. The problem is not when things are going swimmingly; it is when the gremlins in the machine strike.