RC1 error message

[edstaffin]

Take a look at the attached screenshot.
Since I installed RC1 I am getting this strange error message from a running strat. It tells me to look in the help guide for info on transitioning order references from historical to live ..., but I can't find anything. What's causing this? As far as I know I am dealing with live data and why I should get an error regarding historical data is beyond me.
Thanks ... Ed

[NinjaTrader_PatrickH]

Hello edstaffin,

Thank you for your post.

This is in place to avoid historical orders not being tied to real-time orders. As we now have access to the Order object itself the historical Order object is not going to be the same as an order that is submitted in real-time.

Utilize the GetRealtimeOrder() method described at the following link to avoid the message and appropriately assign historical order objects to live orders: http://ninjatrader.com/support/helpG...ltimeorder.htm

[edstaffin]

I have updated my code accordingly.Thanks for the tip. The only thing that bothers me is that this code has been running for months without this error. I installed RC1 and I started getting quite a bit. Does this make sense? Was there some change in RC1 that caused this or is it just a coincidence?
Thanks ... Ed

[NinjaTrader_PatrickH]

Hello edstaffin,

Thank you for your patience.

There was no message given previously when attempting to move the historical orders in real-time. The documentation is updated now and you can find more detail at the following link under "Transitioning order references from historical to live": http://ninjatrader.com/support/helpG...r_handling.htm

[DaveE]

I am puzzled as to why in the 'managed' environment, users are supposed to remember to, at State.Realtime, find all their active Order references and call GetRealtimeOrder on them all.
This hardly seems 'managed'
GetRealtimeOrder is documented under

Advanced order handling is reserved for EXPERIENCED programmers

But the scenario of

having active historical order(s) and transitioning to realtime

is hardly an advanced scenario!
Why cant the 'managed system' do something like this automatically?
I assume that there must be a (currently hidden and undocumented) collection in NT of active 'internal' orders, perhaps called ManagedActiveOrders. I assume that when NT moves to realtime then ManagedActiveOrders gets updated, but the user's order references obtained during Historical period were perhaps clones of elements in the collection, so don't get automatically updated.
One simple solution would be to make public the currently hidden ManagedActiveOrders. This could avoid the need for users to call GetRealtimeOrder. It would also presumably contain other useful information that is currently hidden (such as the due-for-auto-expiry DateTime for limit orders)

[edstaffin]

Heck, let's take it a step further. Why not open source the managed code base? People spend a lot of time reinventing it to do unmanaged code. NT would benefit from a much wider peer review and like a better "managed" product over time. Users would benefit from not having to reinvent the wheel. Having a code library of unmanaged code that I could tweek would be enormously useful. There's too much crap code floating around.
What do you think?
Thanks ... Ed

[DaveE]

Sounds like a good idea. But they might be worried about embarrassing code or increasing their support workload.
However I suspect that a significant proportion of the current support workload might be due to shortcomings in the 'managed' system.
For example

• ambiguous error messages,
• Bugs that are hard to work-around due to 'managed' using undocumented, hidden information (such as "ManagedActiveOrders").
• Lack of support for common scenarios (such as oco entry bracket).

[edstaffin]

Rather than increase the workload, open sourcing would decrease it. Schmuck's like us would do the heavy lifting and come up with creative solutions to various problems. They would just have to review/approve. No losers.

[NinjaTrader_Matthew]

Why cant the 'managed system' do something like this automatically?

NT7's IOrders were just a proxy of the core order object. This allowed us to do things like updating your reference to the order, etc - but this implementation was also self-limiting and the IOrder proxy did not expose all of the information of the core order. There was also a performance impact in this implementation and could lead to race conditions where the core object updates before the proxy order had updated

NT8 we have now exposed direct access to the core order object. Since you as a 3rd party developer are storing a local reference to the direct order object, we have no way to update the locally stored object reference to your class. It is a chicken an egg scenario since you have already stored the order object reference while it was historical, therefore you would need to update that order reference at some time when it transitions. We fully understand this is not as user-friendly, but we've changed this behavior at the benefit of exposing direct core information to 3rd party developers which enable them to do more with these orders than ever before.

This hardly seems 'managed'
GetRealtimeOrder is documented under
But the scenario of is hardly an advanced scenario!

We would consider any sort of order reference tracking a more advanced concept since it requires an understanding of object-oriented programming concepts. It is not required to use any of these advanced OOP concepts to use the managed framework methods since that will handle canceling and changing orders for you if used correctly - but if you want to work outside of that frameworks management, you then need to use these order objects directly to track and manage them yourself.

One simple solution would be to make public the currently hidden ManagedActiveOrders. This could avoid the need for users to call GetRealtimeOrder.

We have already exposed the core "Order" object directly and the cores OnOrderUpdate() method, so that what you are asking for is implicitly exposed to you. GetRealtimeOrder() is just a helper to assist with this transition, but it is not even needed if you track the order object update itself in OnOrderUpdate(), which will call anytime the core changes an order (which didn't always happen in NT7).

It would also presumably contain other useful information that is currently hidden (such as the due-for-auto-expiry DateTime for limit orders)

This other useful information is also exposed by exposing the order object, but not all meta data you might be expecting is actually stored. For example, there is not a DateTime for limit orders, so we're not hiding anything from you there. You just need to track the current bar the order was submitted to and it will be canceled on the next bar update assuming IsLiveUntilCanceled property was false on the order object. Here is an example of how you could store your own meta deta in combination with that managed order framework if you are using more advanced options

protected override void OnBarUpdate()
{

if (CurrentBar == 20 && enterLong == null)
{
// store the current bar at the time the order is submitted
EnterLongLimit(1, "enterLong");
ordersBar = CurrentBar;
}

// order object is assinged in OnOrderUpdate() as soon as the order is updated in the core
if ( enterLong != null)
{
if (!enterLong.IsLiveUntilCancelled && CurrentBar != ordersBar)
{
Print("Order will be Cancelled here");
}
}
}

protected override void OnOrderUpdate(Order order, double limitPrice, double stopPrice, int quantity, int filled, double averageFillPrice, OrderState orderState, DateTime time, ErrorCode error, string nativeError)
{
// assign order
if (order.Name == "enterLong" && orderState != OrderState.Filled)
enterLong = order;

// unassign order when null
if (enterLong != null && enterLong == order)
{

if (order.OrderState == OrderState.Cancelled)
enterLong = null;
}
}

[NinjaTrader_Matthew]

Heck, let's take it a step further. Why not open source the managed code base? People spend a lot of time reinventing it to do unmanaged code. NT would benefit from a much wider peer review and like a better "managed" product over time. Users would benefit from not having to reinvent the wheel. Having a code library of unmanaged code that I could tweek would be enormously useful. There's too much crap code floating around.
What do you think?
Thanks ... Ed

This is an interesting idea for sure. I've added it to our tracking system using ID SFT-1681

[DaveE]

We have already exposed the core "Order" object directly and the cores OnOrderUpdate() method, so that what you are asking for is implicitly exposed to you.

Of course I can keep track of each Order object returned by managed methods. But what I am asking for is a Collection (something similar to Account.Orders. I suspect this might be sometimes different to a collection that I could build up of individual Order objects.
For example if I use EnterLongLimit(qty x) on bar 0, this gets filled, then I use EnterShortLimit(qtyx) on bar 1 then I only get one Order object (qty x) returned from EnterShortLimit, but I see two Position updates (one takes it to Flat, 2nd takes it to Short qty x), which makes it look like NT is using two 'hidden' Short orders of qty x. I am assuming these two orders are in a currently hidden collection.

You just need to track the current bar the order was submitted to and it will be canceled on the next bar update

Sometimes this is not working correctly example here

[NinjaTrader_Matthew]

For example if I use EnterLongLimit(qty x) on bar 0, this gets filled, then I use EnterShortLimit(qtyx) on bar 1 then I only get one Order object (qty x) returned from EnterShortLimit, but I see two Position updates (one takes it to Flat, 2nd takes it to Short qty x), which makes it look like NT is using two 'hidden' Short orders of qty x. I am assuming these two orders are in a currently hidden collection.

I'm not quite sure I follow since there is no hidden collection, but if you're looking for us to add some collection of orders I can submit that as a request but I'll need to know specifically what you're looking for:

- A collection of all historical orders submitted on the backtest account
- A collection of only "managed' orders which are submitted in response to your managed order calls?
- A collection of all orders, historical, real-time managed or otherwise?

Just so we're on the same page, all of these orders are updated in your strategies OnOrderUpdate() so it is possible for your to build this collection right now. If you want something baked by the framework, I can submit that as a feature request to consider.