Accepted & Working

[giogio1]

I noticed that on a bracketing, at least in playback, Targets tends to stay in Working state and Stop in Accepted state.
I was wandering why, what it really means but I can't find an explanation in the forum or documentation.

Since I want the code to be also compatible with Rithmic, can I rely on the the state reported in OnOrderUpdate ? particularly for ,working, accepted, filled, partFilled, and Cancelled? I ask because OnExecutionUpdate documentation seems to indicate to not to rely on OnOrderUpdate for quantities.

Especially I see that I should code something similar to what's indicated in the documentation:

/ if entry order exists
if (entryOrder != null && entryOrder == order)
{
 Print(order.ToString());
 if (order.OrderState == OrderState.Cancelled)
{
 // Do something here
 entryOrder = null;
 }
}​
​

I wander if could do that with Rithmic.

Thank you
Gio

[NinjaTrader_ChelseaB]

Hello Gio,

"I noticed that on a bracketing, at least in playback, Targets tends to stay in Working state and Stop in Accepted state.
I was wandering why, what it really means but I can't find an explanation in the forum or documentation."

Different brokerages may have a different state for stop or limit orders being either accepted or working.

In the example found below, this checks for either.

https://support.ninjatrader.com/s/article/Profit-Chase-Stop-Trail

"Since I want the code to be also compatible with Rithmic, can I rely on the the state reported in OnOrderUpdate."

Yes, you can use just OnOrderUpdate() or just OnExecutionUpdate(), but don't rely on the sequence of these updating.

https://forum.ninjatrader.com/forum/ninjatrader-8/platform-technical-support-aa/1199112-ninja-trader-v8-0-26-rithmic-issues-fixed?p=1206372#post1206372

[giogio1]

Thank you, it is getting clearer and clearer. And the link you povided very useful

More questions. I realize there are many and I thank you for the patience. I think I am getting closer to the end...

The following question is regarding this statement in the documentation.
and the notes in the code marked with asterisks ***1 & ***2

I want to remain compatible with Rithmic (whose solution I understand works for Continuum, IB and everything)...

I am referring to the ManagedRithmicIBFriendlyExample

I understand that I should conceptually write something like (it's just a snippet) :

 protected override void OnOrderUpdate(Order order, double limitPrice, double stopPrice, int quantity, int filled, double averageFillPrice, OrderState orderState, DateTime time, ErrorCode error, string nativeError)
{​
          if (stopLossLong1 != null && stopLossLong1 == order))
          {

                   if (orderState == OrderState.Rejected)                  // ***1
                    {
                              ChangeOrder(stopLossLong1, ............
                    }
          }

            //the code below is from ManagedRithmicIBFriendlyExample
            if ((targetLong1 != null && targetLong1 == order)
                || (stopLossLong1 != null && stopLossLong1 == order))
            {
                if (order.OrderState == OrderState.Cancelled && order.Filled == 0)
                    targetLong1 = stopLossLong1 = null;
                if (order.OrderState == OrderState.Filled)
                    targetLong1 = stopLossLong1 = null;                  // ***2
            }​
}

The questions are:
1) somewhere I read that "order" in OnOrderUpdate and execution in OnExecutionUpdate contain the most up to date information from the broker, can you confirm this is true?
In other words what's the difference between order.Quantity and quantity, or order.OrderState and orderState. I remember I read it but I couldn't understand it.


2) ***1 : in general..., is it logically correct, does it make sense to ChangeOrder after rejection in OnOrderUpdate (see code at ***1) ?


3) ***2 : I don't understand how the part of the code of ManagedRithmicIBFriendlyExample reported at ***2. can work.

It seems to me that if the stopLossLong1 has been filled, in order to make the code more reliable this should be detected in OnExecutionUpdate() and there be sent a CancelOrder(stopLossLong1) and CancelOrder(targetLong1) order. Then in OnOrderUpdate(), detect that the order has been Cancelled and only then set targetLong1 = stopLossLong1 = null.

In ManagedRithmicIBFriendlyExample instead, if any of targetLong1 or stopLossLong1 is Cancelled then all bracket is nulled, i.e. both targetLong1 = stopLossLong1 = null;

But when I simply null an iOrder the order could still stay active at the broker.

What's wrong with my reasoning? Or is the code sort of incomplete?

Best
Gio

[NinjaTrader_ChelseaB]

Hello Gio,

"somewhere I read that "order" in OnOrderUpdate and execution in OnExecutionUpdate contain the most up to date information from the broker, can you confirm this is true?"

The order object in OnOrderUpdate() is the most recently updated Order object, the execution in OnExecutionUpdate() is the most recently updated Execution object, however the execution.Order is not always the most updated Order object.

(This is why anything related to the Order object should be accessed from OnOrderUpdate() only, and the execution.Filled should only be accessed from OnExecutionUpdate() only.)

In this aspect the order.Quantity and quantity are the same, but here for quick access.

"***1 : in general..., is it logically correct, does it make sense to ChangeOrder after rejection in OnOrderUpdate (see code at ***1) ?"

No, a rejected order cannot be changed. An error will result. A new order has to be submitted.

"***2 : I don't understand how the part of the code of ManagedRithmicIBFriendlyExample reported at ***2. can work"

Below is a link to an educational C# site on multiple variable assignments.

https://www.w3schools.com/cs/cs_variables_multiple.php

[giogio1]

You have the gift of clarity. Thank you Chelsea.

Regarding the last question, it was not about multiple variable assignment but about the fact that in the ManagedRithmicIBFriendlyExample code, when the target is filled also the stop order is nulled (with stopLossLong1= null, not just the target order gets nulled).
Yet the documentation says that setting an iOrder = null doesn't cancel the order which may stay active. So I need an explanation for this incongruency.
In other words should I cancel any order first, prior setting their iOrder to null? All my orders are LiveUntilCancelled.

The second question is: The signature of OnOrderUpdate provides both Order order as well as 'int quantity' and 'OrderState orderState'.
Since I can access the last two from the 'Order order' I wander if 'int quantity' and 'OrderState orderState' sometimes provide different additional information to order.Quantity and order.OrderState.

Thank you.
Gio

[NinjaTrader_ChelseaB]

Hello Gio,

Setting a variable to null does not cancel an order.
The example script is setting variables to null after the orders are already rejected or filled (and no longer working) so that the logic knows to place new orders.

Yes, if you want to cancel an order, the variable needs to be holding the order you want to supply to CancelOrder().

No, from my understanding the quantity and order.Quantity will be the same in OnOrderUpdate().

[giogio1]

Few questions and thank you for your patience. I am actually getting to destination and hopefully other people will find this thread useful.

Even though I'll figure it out debugging, I'd like to ask you, based on your experience, If have almost no errors, in playback and some in Sim101. In general when I have no execution error in playback and few with quantity much greater than 2, what should I mostly look for?
The question could be too vague and the answer too broad and if so, please don't answer.

My main questions are.
1)
You answered me: "No, a rejected order cannot be changed. An error will result. A new order has to be submitted."
I understand that a rejected order is de-facto also cancelled and I can treat it as cancelled. Which means that I could set it's associated iOrder equal to null. (i.e.I can write: 'if (orderState == OrderState.Rejected) stopLossLong1 = null;')
Correct?

2)
Can the new order (after rejection) be submitted from the OnOrderUpdate block or I should set a flag and have it re-Submitted as new from OnBarUpdate?

3) And if instead I want to just Exit all positions and cancel all orders also I can or cannot from the OnOrderUpdate block ?

4) (Referring to ManagedRithmicIBFriendlyExample)
Why the code writes: "if (order.OrderState == OrderState.Cancelled && order.Filled == 0)"
and not simply if (order.OrderState == OrderState.Cancelled ? If Cancelled the Filled quantity should be always zero, correct?

5) (Referring to ManagedRithmicIBFriendlyExample)
If I use Rithmic, can I test Position.MarketPosition to see if I am flat or I must always only rely on sumFilledLong1 ?

Thank you Chelsea for these clarifications !
Gio

[NinjaTrader_ChelseaB]

Hello Gio,

"I understand that a rejected order is de-facto also cancelled and I can treat it as cancelled. Which means that I could set it's associated iOrder equal to null. (i.e.I can write: 'if (orderState == OrderState.Rejected) stopLossLong1 = null;')
Correct?

A rejected order is no longer working or accepted if this is what you mean.

If your logic needs to clear the variable of an object after a rejection or cancellation yes you can set the variable to null.

"Can the new order (after rejection) be submitted from the OnOrderUpdate block or I should set a flag and have it re-Submitted as new from OnBarUpdate?"

You can send orders from OnOrderUpdate(). That said, if the order is a replacement order you will want to ensure the price is different so it also does not get rejected. (To avoid an endless loop of rejected order, replacement order, rejected order, etc)


"Why the code writes: "if (order.OrderState == OrderState.Cancelled && order.Filled == 0)"
and not simply if (order.OrderState == OrderState.Cancelled ? If Cancelled the Filled quantity should be always zero, correct?"

If an order is part filled and does not continue filling the remaining quantity can be cancelled.

"If I use Rithmic, can I test Position.MarketPosition to see if I am flat or I must always only rely on sumFilledLong1 ?"

You can use the Position.MarketPosition from OnPositionUpdate() or OnExecutionUpdate(). But do not use the execution.Order.Filled as the order object may not be updated when OnExecutionUpdate() runs.

[giogio1]

Excellent. things are working now!

Still questions... Thank you Chelsea.

Referring to ManagedRithmicIBFriendlyExample with it's 100 contracts for testing....

In OnExecutionUpdate I have ChangeOrder(stopLossLong1, ....

If stopLossLong1 order gets Rejected during the ChangeOrder(), what happens to the stop loss order prior the attempt to alter it? Does it get cancelled and removed from the exchange or NinjaTrader servers too?

Best
Gio

[giogio1]

Referring to ManagedRithmicIBFriendlyExample, in OnExecutionUpdate I have ChangeOrder(stopLossLong1, ....

If stopLossLong1 order gets Rejected during the ChangeOrder(), what happens to the stop loss order prior the attempt to alter it? Does it get cancelled and removed from the exchange or NinjaTrader servers too? I'd like to have clarity on this to understand if I need to keep a list of the iOrders that get modified.
Thank you!
Gio

[NinjaTrader_ChelseaB]

Hello Gio,

When an order is 'Unable to change order' the order will remain working at whatever previous price it was working at.

Note, if the strategy is set to disable on order error, this would cause any working orders to be cancelled by the strategy disable.

[giogio1]

In the UnmanagedRithmicIBFriendlyExample.cs it says
/* We advise monitoring OnExecution to trigger submission of stop/target orders instead of OnOrderUpdate()
since OnExecution() is called after OnOrderUpdate() which ensures your strategy has received the execution
which is used for internal signal tracking. */

Despite this recommendation, for monitoring the positions, I have interest in using order.Filled in the OnOrderUpdate() body execution to determine the positions actually filled because i never get it incorrectly.

It works well in playback101. Would that work with Rithmic (apex)?

Best
G

[NinjaTrader_ChelseaB]

Hello G,

As long as you are only using OnOrderUpdate() and not mixing code in OnExecutionUpdate() this would be fine.

[giogio1]

Hi Chelsea,
I realize I don't have clarity around positions calculations with Rithmic because referring to a code derived from RithmicIBFriendlyExample sumFilledLong1 is used from OnExecutionUpdate to correctly evaluate the positions on a Rithmic account.

It is about the reliability of the account/Positions information with Rithmic.

From the following lines you may be able to figure out where my confusion is.


Maybe this sumFilledLong1 is necessary to instantly and correctly update the bracket quantity.

If so

Once in a while I want to double check when my positions are flat for the sole purpose of checking that the sumFilledLong1 is actually correctly synchronized with the account positions.

So I used a code that looks like:

            if (account.Positions.Where(o => o.Instrument == Instrument).Count() > 0)
            {
                myPosition = account.Positions.Where(o => o.Instrument == Instrument).Last();
            }
            int posSize = accountPosition.Quantity;
​

With Rithmic/Apex is the account/Positions at times meaningful (and so I can use the code above) or I must only rely on sumFilledLong1 ?

Or it is just OnPositionUpdate() that it is not reliable with Rithmic.?

And so with Rithmic which is the correct way to check if I am long or short?

Thank You.
Gio

[NinjaTrader_ChelseaB]

Hello Gio,

As the order may not be updated before the execution, the execution.Order.Filled may not be correct.
The sumFilled tracks the amount of part fills accurately from OnExecutionUpdate() to give an actual total of the filled amount.