Unable to clean up an un-submitted Order object created with Account.CreateOrder.

[ntbone]

Using the documentation found

https://ninjatrader.com/support/helpGuides/nt8/en-us/createorder.htm

the following code creates an order that cannot be deleted when using simulation accounts.

void SubmitAnOrder90
{
    Order stopOrder;
    stopOrder = myAccount.CreateOrder(myInstrument, OrderAction.Sell, OrderType.StopMarket, OrderEntry.Automated, TimeInForce.Day, 1, 0, 1400, "myOCO", "stopOrder", Core.Globals.MaxDate, null);

    if(TestSomeMarketCondition() == false)
    {
        myAccount.Cancel(new[] { stopOrder });  // with or without this, we end up with an orphaned order
                                                // that cannot be deleted, canceled or removed from simulation accounts
        return;   
    }

    myAccount.Submit(new[] { stopOrder });
}

The simulation account will either end up with an order stuck in the "Initialized" state, or an order stuck in the "Cancel pending" state. How does one properly clean up orders created with CreateOrder but never submitted?

[NinjaTrader_ChelseaB]

Hello ntbone,

If the order was never submitted, you can set the variable to null. The garbage collection will clean up it up eventually. You will need to create a new order after that.

Below is a link to an example you may find helpful.
https://ninjatrader.com/support/foru...720#post820720

[ntbone]

Thanks. I read through the thread and the example code in that thread but it dind't provide me with an answer.

If I call CreateOrder, but then don't call Submit on that order, it will forever show up in the list of orders as initialized.
If I call CreateOrder, but have a code path that decides not to submit, and instead I call Cancel, the order is left in an "cancel pending" state.

After that, my only recourse to get rid of the orders is to reset my database. I have not tried this with a real broker vs a simulation account.

I have found that if I explicitly set the order state to Canceled, then everything appears as expected.

What I am looking for is the official way to clean up an order that is created with Account.CreateOrder but for which Account.Submit is never called.

[NinjaTrader_ChelseaB]

Hello ntbone,

There isn't code to remove orders from the database once they are created.

If you don't want to submit them, i would recommend you do not create them.

Creation and submission should happen at the same time.

You can choose to ignore them if you want.

[ntbone]

I understand that they should happen at the same time, but since the operations are not atomic there is always the possibility of error, without a chancel for clean up. Consider the follwoing

var order1 = account.CreateOrder(...);
var ordre2 = account.CreateOrder(...);
var order3 = account.CreateOrder(...);
...
var order 8 = account.CreateOrder(...);

account.Submit(new [] { order1, order2, order 3, ....order 8};

There are problems that can come up during creation of those orders. CreateOrder could fail for some reason, an execption could be thrown while trying to figure out the information to be placed inside the orders.

In this case the orders might have a one cancels all situation so it doesn't make sense to submit them one at a time.

Not providing a means to properly clean up, perhaps in a catch(...) block, results in non-robust code. There doesn't nee to be code to necessarily delete the orders from the database. Just code to properly abort or cancel orders that have not been submitted. The API leaves developers up to writing code that can corrupt the database and leave pending orders without anyway to properly clean them up.

[NinjaTrader_ChelseaB]

Hello ntbone,

It shouldn't cause any issues to ignore the order. Set the variable to null, and then ignore the order. Once an order is created in the database, there isn't a way to remove it other than resetting the account.

This is true for orders being made internally by the core of NinjaTrader as well.

[ntbone]

The problem is the orders remain in the initialized state which makes them stick out in the UI. Setting the state of the order explicitly to canceled seems to remedy this.