OnExecution() gives "Object reference not set to..." error

[noincomenojobnoassets]

Hi guys,

I have this very basic tryout strategy using two IOrder objects LongEntry and ShortEntry:

OnBarUpdate:
-> if IOrders are != null, set them to = null.
-> if Close0 >= Open0 and LongEntry is null, LongEntry = EnterLong();
-> if Close0 < Open0 and ShortEntry is null, ShortEntry = EnterShort();

OnExecution:
-> if LongEntry != null and LongEntry.Token is execution.Order.Token, Print "Long"
-> if ShortEntry != null and ShortEntry.Token is execution.Order.Token, Print "Short".

Okay, what happens is: as long as the strategy keeps going long or short into the same direction, it all works fine. The position is increased and the Prints keep coming. Now: When the strategy "turns", meaning it changes a 5-long position into a 1-short position because of a red bar after 5 green bars, it crashes giving the "object reference not set to an instance of an object" error. It all works fine in 6.5, however.
(I'm using NT7b3 right now.)

Help would be greatly appreciated!

Thanks,

noincome

[NinjaTrader_JoshP]

noincome,

Please first update to NT7B4 and try again. Thank you.

[noincomenojobnoassets]

same problem with b4.

[HT101]

I also have the same issue.

[NinjaTrader_Dierk]

What exactly do you mean by
>> it crashes giving the "object reference not set to an instance of an object"

- is there a log entry?
- do you get any error message from NT?
- else?

[HT101]

This is what the error looks like - give me a minute and I will post a strategy so you can reproduce.

[HT101]

Obviously this is modified from the examples. Let me know if you need anything else.

[NinjaTrader_JoshP]

HT101 and noincome,

Please see the IOrder in Strategies section of here: http://www.ninjatrader-support.com/H...er_30_2009.pdf

Instead of checking Tokens you want to directly check the IOrders.

[HT101]

Thanks - worked great.

[noincomenojobnoassets]

For me, too! Thanks!

[Aussie2]

Josh,

Am I right in my IOrder assumptions below?

As best I can figure:
1 Setting an order to null just severs the association/link to that order, and does not delete the order.
2 Setting an order to null may produce errors if order processing is not complete.
3 Accordingly prior to setting an order to null we should test order status for OrderState.Filled, OrderState.Cancelled, and OrderState.Rejected
4 So it is probably better not to set orders to null at all !
5 When a strategy starts and there are no orders, the IOrders will = null. After the first order is presumably inialized a token is issued.

Thanks.

[noincomenojobnoassets]

G'day mate,

My guess would be:

1 - setting it to null removes the information from the IOrder object, such as order price/type/...

2 - I'd say yes, it may produce errors. If you set it to null and then try to access order price/type/etc., it won't work.

3 - I usually set it to null after it's done what it was supposed to do - for instance, I have the order do something OnExecution and then set it to null at the next OnBarUpdate. Most important thing is to check for != null before setting it to null: if (MyOrder != null) {MyOrder = null;}

4 - I've had trouble "reusing" used IOrder objects, so I'm cleaning them by setting them = null before reusing the same IOrder object.

5 - I'd say so, too.

Note: This is almost all NT 6.5 experience - please prove me wrong if something has changed for v7. (or if I'm wrong in some other way )

[NinjaTrader_JoshP]

noincomenojobnoassets' responses are valid. Thank you.

[Aussie2]

Why set an IOrders == null ? Why use an IOrder array?

Thanks Guys, I have been using SubmitOrder() and ChangeOrder() methods so understanding IOrder objects precisely is a great help.

However I still cannot see exactly what benefit there is in setting my IOrder == null when you can just test for .Working .Cancellled .Rejected etc

noincomenojobnoassets statement suggests difficulties result if you do.

4 - I've had trouble "reusing" used IOrder objects, so I'm cleaning them by setting them = null before reusing the same IOrder object.

I expect (guess) if your strategy has multiple entry signals then setting the IOrder == null, and then testing for a null condition prior to a new entry, could prevent "unwanted additional entries". I prefer to test for .Flat .Long etc as this would seem a safer solution.

Similarily an NT user might expect that if you want these "additional entries" to be processed concurrently then they would need an IOrder array to handle the additional orders. I have read several posts that mention IOrder arrays. But my preliminary testing suggests otherwise. For example I can include two identical buy orders, with one on the line after the other (ie sharing the same entry rule), and they seem to process and fill.

myBuyOrder=SubmitOrder(1,OrderAction.Buy,OrderType.Market,1,0,0,"","9 BuyDummy");
myBuyOrder=SubmitOrder(1,OrderAction.Buy,OrderType.Market,1,0,0,"","9 BuyDummy");

So why use an IOrder array either?

[NinjaTrader_Ray]

I guess there are many ways to skin a cat and whatever approach you decide to use may be dependent on what your requirements are. Debating the use of an array or variables really is a C#/programming level question. If you only deal with one entry and one stop/target, variables might be the way to go. If you are managing an undetermined amount of orders, an array might be the way to go etc... Your call.