CancelOrder...

[jeronymite]

Thanks for the update, Mark--. Seems like it is probably not a factor, at least from the perspective of performance after significant growth.

Thanks.

[NinjaTrader_Emily]

Thanks for the response.

OK, I changed the example, attached, to use TriggerCustomEvent(), and was able to test a few times. No change.

Cheers,

Mark

Hello Mark,

Thank you for the update.

You may see different results from using the WPF Dispatcher timer rather than a system timer from the Timer Class. As noted on the help guide page for TriggerCustomEvent, "Usually the correct approach is to use the WPF Dispatcher timer, however in cases where you need the timer to update a WinForms window it opened - please use the WinForms timer."

For examples that use a DispatcherTimer, please see the following post:
https://forum.ninjatrader.com/forum/...185#post777185

Here are links to the publicly available Microsoft information regarding the DispatcherTimer and Timer classes:

• https://learn.microsoft.com/en-us/do...imer?view=netframework-4.8
• https://learn.microsoft.com/en-us/do...tframework-4.8

That said, you could achieve the same result of canceling the entry order 5 seconds after it is submitted without using a timer altogether. You could store DateTime.Now.AddSeconds(5) to a variable once the entry is submitted, then have a condition that checks if the current time is greater than the time stored in the variable. If so, call the CancelOrder() method. I have modified the SampleCancelOrder script to include this logic. Please see the attached script:
FiveSecondCancelWithoutTimer.zip

TraceOrders is enabled in this script so you may see when the entry order is submitted and canceled in the NinjaScript Output window.

As an additional side note, I see that you and jeronymite discussed the Reset DB function. This can clear historical orders and executions from the database as described here:
https://ninjatrader.com/support/help...ns.htm#ResetDb

Please let me know if I may be of further assistance.

[Mark--]

Please let me know if I may be of further assistance.

Hello,

Thanks for the response.
I am confused.
Did you run the sample I supplied and have the same result?

Also the link to the zip file is bad.

Mark

[Mark--]

...

Your assistance is appreciated and I did learn something, always a good thing.

Mark

[jeronymite]

Mark-- Please correct me if need be. My understanding is that you are submitting Orders, which you then subsequently Cancel, and the time between submitting the Cancel and seeing that actioned in OnOrderUpdate can be anything from a few seconds to tens of seconds? In other words, Cancelling an Order can take a vast amount of time to even begin to happen after it is requested. Meaning, of course, that submitted Orders that are subsequently Cancelled may very well be Filled in the time between submitting the Cancel and when that Cancel is actioned. That, of course, creates a situation that was intended to be avoided in the first place. Is that what your report is about?

Thanks.

[Mark--]

Is that what your report is about?

Pretty much. But it has changed to the CancelOrder call seems to do nothing until end of bar (minute).

In essence CancelOrder is not doing anything detectable and certainly not cancelling the order in a reasonable time. The example I posted demonstrates the issue very well, using the simulator. Order placed on 5 seconds after the start of the minute, cancel order called at 10 seconds after the minute. Order does not actually cancel for 50 seconds.

[NinjaTrader_Emily]

Hello Mark,

Thank you for your patience.

I checked your script and it is using a system timer object and not the WPF Dispatcher timer object that is recommended on the TriggerCustomEvent() page:

https://ninjatrader.com/support/helpGuides/nt8/triggercustomevent.htm

You reported that the behavior still occurs, though since you are not using the recommended type of Timer I made some suggestions on how to use the recommended type of timer including the link to a colleague's post with examples that use a WPF Dispatcher timer. If you would like to continue with the use of a timer, please try changing the type of timer used according to the recommendations.

As for the .zip file, I see the link inside of the "Attached Files" box at the bottom of my reply does work. I edited my post to correct the link embedded within my reply as well. The example I created is intended to show you how to achieve the desired CancelOrder() result without using a timer, as the timer seems to be related to the delay you are seeing with CancelOrder() and calling CancelOrder() from within a timer event processor is likely not the most ideal use of a timer. My understanding is that a timer is not needed to achieve your desired result of canceling an order 5 seconds after it is submitted, and my example shows how to do that with a DateTime.Now comparison to the time the order is submitted plus 5 seconds.

I appreciate your time and patience. Please let me know if you have any additional questions or concerns.

[Mark--]

NinjaTrader_Emily

Thanks for the response.
OK you did NOT run the example and see the results. No problem.

[jeronymite]

Apologies if I am missing the point here ... but isn't the issue related to the duration between submitting the Cancel and its actual execution?

Whether you submit by timer or manually, if a CancelOrder has been submitted, one would expect that to be actioned immediately, and to see the results within moments (a human-perspective duration that should be more than sufficient for a technologically-based action).

If this is not the issue being discussed, some clarity on the matter would be appreciated. If it is the issue being discussed, why is the duration between submitting CancelOrder and its execution so vast?

Thanks.

[Mark--]

Apologies if I am missing the point here

You are not missing the point, it is exactly the point but, I was unable to successfully communicate it.
Calling CancelOrder from anywhere in a script, should cancel the order immediately, IMHO.

So I am going with the flow (guidance) and changed the timer type to "System.Windows.Threading.DispatcherTimer" and will test later when the market opens.
If it works, great.

From what NinjaTrader_Emily has posted, using a system timer for CancelOrder is the problem. What other calls should not be made via a system timer?

Mark

[Mark--]

OK replaced the system timer with a System.Windows.Threading.DispatcherTimer.

No change. Same result.

Attached is the changed example.

[Mark--]

NinjaTrader_Emily, thanks for the example.

I looked at it, ran the strategy and it seemed to work and then seemed to not work.
Adding a print time in OnBarUpdate shows why.
In slow market times OnBarUpdate is not called.

3/7/2023 6:39:03 PM Strategy 'FiveSecondCancelWithoutTimer/289674779': Entered internal SubmitOrderManaged() method at 3/7/2023 6:39:03 PM: BarsInProgress=0 Action=Buy OrderType=Limit Quantity=1 LimitPrice=3987.00 StopPrice=0 SignalName='long limit entry' FromEntrySignal=''
6:39:04 PM bar update
6:39:04 PM bar update
6:39:08 PM bar update
6:39:08 PM bar update
6:39:08 PM bar update
6:39:08 PM bar update
6:39:08 PM bar update
6:39:08 PM bar update
6:39:08 PM bar update
6:39:08 PM bar update
6:39:08 PM bar update
6:39:08 PM bar update
6:39:08 PM bar update
6:39:08 PM bar update
6:39:22 PM bar update
3/7/2023 6:39:21 PM Strategy 'FiveSecondCancelWithoutTimer/289674779': Cancelled custom managed order: orderId='1a19188d366340f5acfabc2c978fd126' account='Sim101' name='long limit entry' orderState=Working instrument='ES 03-23' orderAction=Buy orderType='Limit' limitPrice=3987 stopPrice=0 quantity=1 tif=Gtc oco='' filled=0 averageFillPrice=0 onBehalfOf='' id=57 time='2023-03-07 18:39:03' gtd='2099-12-01' statementDate='2023-03-07'
6:39:22 PM bar update

The "DateTime.Now > fiveSecondsAfterEntry" in the bar update missed the 5 second window and was 20 seconds before the cancel order was called.

This happened many times at different lengths. The order needs to be cancelled regardless of other operations.

So it seems another solution is needed. Ideas?

It is interesting that in this capture, the bar update time (using) DateTime.Now.ToLongTimeString()) "6:39:22 PM bar update" is before the next entry placed in the output window by the system.

Mark

[jeronymite]

Mark-- Discovering that behaviour is progress. Some thoughts:

• Relying on OnBarUpdate, even with Calculate.OnEachTick, is not a reliable way to ensure certain actions take place in a timely manner, as seen here when the market is slow
• Time-sensitive actions require strictly "time guaranteed" triggers
• Whilst OnBarUpdate with Calculate.OnEachTick might act quickly in a fast market, provision needs to be made for when that is not the case
• Using a Timer as a "heartbeat" is one way to go -- whether it is a System.Timer or a DispatcherTimer does not seem to matter much
• Choose a frequency that makes sense for your need -- too frequent is almost as bad as not frequently enough
• Such a heartbeat can check the status of the required outcome prior to taking action -- if the required action has already been taken, no further action needed
• When necessary, TriggerCustomEvent should be used to trigger actions
• Some form of interlocking is advisable, so that there is no risk of both the Timer and OnBarUpdate both performing the action -- be careful to avoid deadlocks
• If both Timer and OnBarUpdate invoke the same method, there is scope for the method to include coordination and interlocking

That type of approach should work for what you want. Hope those ideas help.

Thanks.

[Mark--]

Thanks for the post.

>Time-sensitive actions require strictly "time guaranteed" triggers

Yes that is why I start a timer when the order is placed.

>Using a Timer as a "heartbeat" is one way to go -- whether it is a System.Timer or a DispatcherTimer does not seem to matter much

Right I am getting the same failed result with both timer types.

>Such a heartbeat can check the status of the required outcome prior to taking action -- if the required action has already been taken, no further action needed

I just want to cancel the working order, not other actions to monitor.

>When necessary, TriggerCustomEvent should be used to trigger actions

Yes, the timer event calls a TriggerCustomEvent setup function and it calls CancelOrder and the order is not cancelled, no error is generated.

Something is amiss. I hope someone at NT runs the last example I posted and finds the issue.

[KonstantinosNT]

I would appreciate it if I had the chance to Cancel an Order I have sent, in case the Market conditions have just changed and the just sent Order:
a) is not good anymore, b) is still unfilled so I (theoretically) have the chance to Cancel it.

For such an Order canceling to be effective, it must be fast enough (meaning: before the Order get filled) and I think that depends on how fast your computer is to quickly compute and send the Cancel, and how fast your internet connection is, to quickly transmit the Cancel Order.

I have sometimes been in the position to wanting to Cancel a specific Order, just a few seconds after my Strategy made it, but I haven't achieved that yet.
Theoretically I have had the required time (some critical seconds) to Cancel before the Order got filled, but in reality, such an «in-time» Canceling doesn’t really work fast enough inside a Strategy.
Maybe I can't write the right / efficient code to do that: I want the decision to initiate a Cancel to be based not on a timer but on certain Market conditions (I can code that), but I can't make it happen immediately. It always delays and becomes useless. Maybe my hardware and connection are not fast enough.

I am very interested in your ideas about how could someone practically implement a fast Order Cancel procedure in a Ninjascript Strategy.