GetRealTime order returns null

[traderpards]

I reported this before but nothing ever came from it...

I'm getting an exception (attached). It tells me to see the help guide, which tells me I need this code:

            else if (State == State.Realtime)
            {
                // One time only, as we transition from historical convert any old historical order 
                // object references to the new live order submitted to the real-time account
                // We only want to make this call on the entries because while transitioning into a 
                // realtime order it turns those stops and targets into live trades.
                if (EntryShort != null)
                {
                    EntryShort = GetRealtimeOrder(EntryShort);
                }
                if (EntryLong != null)
                {
                    EntryLong = GetRealtimeOrder(EntryLong);
                }
            }

The problem is, EntryLong is null because GetRealTimeOrder returned null, even though the documentation says it will return an order object if an order exists, an order really does exist. When the chart loads, a historical order is displayed on the chart and the order ID is an NT- number.

For now, I can get around this by setting Wait Until Flat, but a user might want to select Immediately Submit, which will throw this exception because of the trailing stop code I have in there.

[NinjaTrader_AlanP]

Hello traderpards,

Thank you for your note.

Without the full code we're unable to test on our end.

If you'd like to upload the full code or a sample script with detailed instructions on how to replicate, I can take a look and see if anything jumps out. Or if you'd prefer to email a copy, send to platformsupport[at]ninjatrader[dot]com with Attn: Alan P in the Subject line. Also within the email please include a link to this thread, and the files.

I look forward to your reply.

[traderpards]

It's really easy. All you need to do is pick out one of your MA strategies and put a break point in OnStateChange where State == State.RealTime... Here is one of mine attached.

I have one and I also included a before/after screenshot. As you can see, Entry has a historical order value and after the call to GetRealTimeOrder() its value is now null.

My other strategy will place an order on top of a historical order and if I don't catch it and cancel it, I end up with CancelPending orders you can't do anything with all over the place.

Steps to reproduce:
1. Load EMAtest
2. Launch Visual Studio like you already know how and place a break point on Line 91.
3. Load the strategy on a 5 minute chart with just about any instrument and verify that you have a historical order. If you don't, try another instrument. At this time, 6J issues a historical order. (Or you can increase the profit target until you get one that doesn't get filled.)
4. Observe GetRealTimeOrder() returning null.

Easy peasy.

[NinjaTrader_Jim]

Hello traderpards,

Thanks for providing an example and steps to reproduce. It is much appreciated.

Unfortunately, I am unable to import the strategy due to a dependency on a custom namespace.

I haven't had issue transitioning orders to Realtime using the SampleOnOrderUpdate strategy. It is typically good practice to submit orders on a single tick data series when using Immediately Submit so the orders can be matched more accurately so I typically add a 1 tick data series for order submission when testing.

From the help guide:

* A previously generated order is considered to match an active strategy order when the order action, order type, quantity, limit price, and stop price are exactly identical.

When I test the attached strategy against ES 03-18 with 1 minute data, I am able to have the strategy place target and stop loss orders, and I am able to have the strategy resume with Immediately Submit set and reloading the NinjaScript with F5.

Are you able to expose the same behavior with the attached strategy so we can take a closer look?

I'm happy to look into this matter further with you.

[traderpards]

Good morning Jim,

Sorry about that... I removed the mouse stuff but forgot the using statement...

I loaded your strategy and you're nulling the entry order when it gets filled so it will never be called on GetRealtimeOrder(). I need my entry order throughout the life of the trade so I don't set it to null until the trade closes completely. But even so, the targets and stops will call GetRealTimeOrder() in this strategy and it returns null for those too.

I did comment out where you're nulling the entry order and jacked up the stop loss and profit targets so I'd get a historical order on a 1-minute chart. GetRealTimeOrder() returns null.

Is that what's supposed to happen? I'm under the impression I need to bother with this because of this issue: https://ninjatrader.com/support/foru...ad.php?t=94400 where historical profit targets and stop losses cause unwanted trades in the opposite direction when you use Wait Until Flat.

Can you do what I did and see if you get what the docs say you get?

Thanks!

[NinjaTrader_Jim]

Hello traderpards,

I think there may be some confusion on the usage of GetRealtimeOrder().

GetRealtimeOrder() will be used to transition Order objects from active historical orders to the live orders that are matched with the Immediately Submit behavior. It would still be good practice to null the Order object once it has been filled so it can re enter. If you do not set the order to null after filling, you could come across a situation where the Order object itself is not null, GetRealtimeOrder() looks up an order that is not live and active, and has nothing to return.

Let's say my entry order got me into a 1 long position and I now have an active PT and SL. My entry order will be null since the order filled and is no longer active. The active orders for my PT and SL are what would be needed to transition to realtime if I were to disable/re-enable the strategy.

On disabling and re-enabling, GetRealtimeOrder() would then check if the PT and SL submitted from historical processing exist in realtime and will be matched with accordance with the Start Behavior. We wouldn't need to do this for the entry order, because it is already filled and should be null.