Hello,
I have a personal add-on that extends chart trader and among other things, manages OCO brackets for stop, profit target(s), etc. and I wanted to clarify the use of Account.Change() vs Account.QueueChange() and when (if ever) to explicitly call QueueChange().
Right now, I have a method to handle order changes that is as follows:
public void TryChangeOrder(Order order)
{
} }
Essentially, the idea is that is an order is not in a state to handle a change, I either discard it (order has been filled, cancelled, etc.) or queue it (it is in the process of being changed already). As you can see in the code, I currently exclude Rithmic (Provider14) and always call Change(), as the API (or NT implementation) does not seem to support QueueChange() with Rithmic. For all other providers (Sim, Live and Playback), however, I follow this logic.
However, on certain occasions, I run into issues where it seems that if I call QueueChange() multiple times (e.g., an order is being partially filled and I need to modify stop and/or target quantities), there are intermittent occasions when not all of the changes seem to be processed.
If I remove this and just call Change(), it seems to then work fine in Sim even when always forcing partial fills, but the reason I added the QueueChange() in the first place was because I had issues with Continuum at the very least, though there is the potential for others to exhibit the same problem.
So, before I make any changes, I wanted to see if you could offer any clarification on this? I do see that even when calling Change(), QueueChange() is called when the order is already in a ChangePending or ChangeSubmitted state - at least in Sim.
So, maybe I shouldn't be calling QueueChange() directly at all?
Thanks!
I have a personal add-on that extends chart trader and among other things, manages OCO brackets for stop, profit target(s), etc. and I wanted to clarify the use of Account.Change() vs Account.QueueChange() and when (if ever) to explicitly call QueueChange().
Right now, I have a method to handle order changes that is as follows:
public void TryChangeOrder(Order order)
{
lock (order)
{
{
if (order.OrderState == OrderState.Initialized ||
order.OrderState == OrderState.Cancelled ||
order.OrderState == OrderState.CancelPending ||
order.OrderState == OrderState.CancelSubmitted ||
order.OrderState == OrderState.Rejected ||
order.OrderState == OrderState.Filled) return;
if (order.Account.Provider != Provider.Provider14 &&
(order.OrderState == OrderState.ChangePending || order.OrderState == OrderState.ChangeSubmitted))
{
order.OrderState == OrderState.Cancelled ||
order.OrderState == OrderState.CancelPending ||
order.OrderState == OrderState.CancelSubmitted ||
order.OrderState == OrderState.Rejected ||
order.OrderState == OrderState.Filled) return;
if (order.Account.Provider != Provider.Provider14 &&
(order.OrderState == OrderState.ChangePending || order.OrderState == OrderState.ChangeSubmitted))
{
order.Account.QueueChange(order, order.OrderState);
}
else
{
else
{
order.Account.Change(new[] { order }).
}
}
Essentially, the idea is that is an order is not in a state to handle a change, I either discard it (order has been filled, cancelled, etc.) or queue it (it is in the process of being changed already). As you can see in the code, I currently exclude Rithmic (Provider14) and always call Change(), as the API (or NT implementation) does not seem to support QueueChange() with Rithmic. For all other providers (Sim, Live and Playback), however, I follow this logic.
However, on certain occasions, I run into issues where it seems that if I call QueueChange() multiple times (e.g., an order is being partially filled and I need to modify stop and/or target quantities), there are intermittent occasions when not all of the changes seem to be processed.
If I remove this and just call Change(), it seems to then work fine in Sim even when always forcing partial fills, but the reason I added the QueueChange() in the first place was because I had issues with Continuum at the very least, though there is the potential for others to exhibit the same problem.
So, before I make any changes, I wanted to see if you could offer any clarification on this? I do see that even when calling Change(), QueueChange() is called when the order is already in a ChangePending or ChangeSubmitted state - at least in Sim.
So, maybe I shouldn't be calling QueueChange() directly at all?
Thanks!
Comment