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

[molecool]

Fyi

I replaced anything related to Tokens with the now simplified Order comparison.

BTW, where do I download B4? I only see the original beta release binary in the download area.

[molecool]

Also getting this

I'm also getting this error although I updated everything in my strategy according to the migration guide. It's happening on some of my strategies and not on others.

[NinjaTrader_Dierk]

We fixed something recently. I suggest trying with next update again.

[NinjaTrader_Ray]

I replaced anything related to Tokens with the now simplified Order comparison.

BTW, where do I download B4? I only see the original beta release binary in the download area.

If you have any of the original beta release announcement emails, click on the download link. This will run the installer.

[r2kTrader]

Aussie,

G'day.

Can you elaborate regarding the dual entry with same info? For example, will they have the same "name" but have slightly different times processing(even by a millisecond) and as such produce different Tokens?

Is the key/unique id the token generated or the signal entry name?

I would like to know what your testing produced.

From my experience w/ IOrders, it's fantastic (with the exception of the Stop Loss bug in 6.5, which has been addressed in 7 so I'm back to it's Fantastic!)

Thanks for your post.

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.



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?

[Aussie2]

IOrders

Aussie,

G'day.

Can you elaborate regarding the dual entry with same info? For example, will they have the same "name" but have slightly different times processing(even by a millisecond) and as such produce different Tokens?

Is the key/unique id the token generated or the signal entry name?

I would like to know what your testing produced.

From my experience w/ IOrders, it's fantastic (with the exception of the Stop Loss bug in 6.5, which has been addressed in 7 so I'm back to it's Fantastic!)

Thanks for your post.

Hello

I agree IOrders are great. I was exploring the nature of the IOrder object reference to ensure better strategy coding - to determine whether to use a different string name in the signature, or a different IOrder name or an array.

I used Print statements in the OnExecution() method, during a simulation, to get order and null states, as the order proceeds from working to filled etc.

My conclusion is that every SubmitOrder produces a new token - and that multiple concurrent live orders can exist under the same unique IOrder name with the same signal name in the signature, to other live orders - because there are unique tokens.

Moreover the central reason for a null test is to deal with if statements that occur during the initial IOrder state before any IOrder is made. ie first few bars. Once the initial/first IOrder has been made then all subsequent checks for == null condition, whether it be with the current position, or a subsequent position, and each order state in between will prove false, unless the IOrder has been set to null manually.

So don't bother setting =null

Finally by using the IOrder array approach we would be able to determine/check the token for each order in the array. But I found in my coding that I didn't really need to know the actual unique token number, but did need to know the order state (ie .Working .Filled etc) and then code based on the order state. (My strategy uses multiple limit order entries to deal with low available volume condition as occurs in after hours futures markets.)

Hence the question why use an array?

What approach have you taken?

[r2kTrader]

Thanks for the reply. I will take a stab, but I am a work in progress as a programmer...

I think the array provides the ability to focus on the orders independent of everything else. For example, you can have same name, same entryorder name, but each will have different tokens. So if you also align trades with your array, you can operate on a per trade basis based on the index of your trade and thus have complete granular control. So I see it is as the most complete way to manage your trade. I would imagine you could enum your array into something more readible or stuff your own name in there as well. I would see this type of model if you made your own trading class in which you want to use the same signature after instantiation, but you might need to manage each instance on its own merit.

Example (and this is extremely rough and vague).

You have a trade class called myTradeClass.

Within that trade class you have a method to manage your trade and simulate a move to breakeven and then proceed with trailing stop.

You have this called on each bar or data update.

you fire a trade from within your strategy (assuming you have instantiated your class / initialized it or whatever using mtc as the object name).

mtc.MyTradeMethod(blah, blah, blah) (whatever you want your sig to be)

Now within your class, you use an array to keep track of the trade, independent of your strategy. This allows you more granular control.

At a minimum, you know which trade was made first and which was last simply by tracking the index.

So your trade manager can do all this behind the scenes using the index id to get the right token, to then do what you want based on your trade managment logic.

That's about the best you will get out of me, because I am actually trying to write something just like I tried to explain above. And I am asking such question on an hourly basis, lol.

If you want to work with me on this, I would appreciate the collaboration. Maybe we can both benefit and get a nice trade class together. Also, I am working with someone else that is more advanced than I am, but I am trying to push forward whatever I can as well as learn what I can.

Hello

I agree IOrders are great. I was exploring the nature of the IOrder object reference to ensure better strategy coding - to determine whether to use a different string name in the signature, or a different IOrder name or an array.

I used Print statements in the OnExecution() method, during a simulation, to get order and null states, as the order proceeds from working to filled etc.

My conclusion is that every SubmitOrder produces a new token - and that multiple concurrent live orders can exist under the same unique IOrder name with the same signal name in the signature, to other live orders - because there are unique tokens.

Moreover the central reason for a null test is to deal with if statements that occur during the initial IOrder state before any IOrder is made. ie first few bars. Once the initial/first IOrder has been made then all subsequent checks for == null condition, whether it be with the current position, or a subsequent position, and each order state in between will prove false, unless the IOrder has been set to null manually.

So don't bother setting =null

Finally by using the IOrder array approach we would be able to determine/check the token for each order in the array. But I found in my coding that I didn't really need to know the actual unique token number, but did need to know the order state (ie .Working .Filled etc) and then code based on the order state. (My strategy uses multiple limit order entries to deal with low available volume condition as occurs in after hours futures markets.)

Hence the question why use an array?

What approach have you taken?

[Aussie2]

Trade Class

r2kTrader, your approach using a trade class is interesting, albeit somewhat more complicated than I have used to date. Although I do use a Trade() method that can be called by several alternate entry signals and find that straighforward. My strategy is complex enough with IceBerg order quantities, limit orders away from the bid/ask mean, simulated stops of all kinds, and real working stops. I have just started running this strategy live on NT7B4, so time will tell whether improvements are necessary.

I suggest that it is still possible to get enough relevant trade information, when a single string name in the signature, or a single IOrder name is used.

For example the profit for closed trade position pairs can be determined using:
Trade myClosedTrades = Performance.AllTrades[Performance.AllTrades.Count;

Similiarly the unrealised profit and loss for a position on the current bar series for a particular asset can be determined with:
myPrelimTradePL=Math.Round(Position.GetProfitLoss( Close[0],PerformanceUnit.Currency)/Math.Max(1.0,(double)Position.Quantity),0);


You note that with a trade class you can "index .. your trade and thus have complete granular control" However you can get necessary control in other ways in OnExecution() by testing the current execution for desired characteristics such as whether a full fill or a part fill has just occurred and whether to place a stop.

If I get time a may explore using a trade class, but I cannot see as yet how to use to an advantage!

[r2kTrader]

Aussie,

You can get control because you know the index id of the trade. You could enum it or whatever floats your boat.

Also, the other benefit is for when you want to do something like this.

Assuming you are long:
Put on a stop loss, BUT ONLY if there are no existing additional orders which are between where I am going to put a stop and current price.

So let's say you have 10 lots working. You are long 3 of the 10, 7 orders now working. But the additional 7 are below the current average price because you want to scale in. Well you don't want to put a stop loss in right where you are willing to buy another lot?

So with an array, you could loop through the orders and find out if any are at or below where your stop would go.

Also, you can use an array and still create a unique id/name. Just use a variable and increment / decrement it as you put on orders.

For example: For a short, you might say "S + orderNumber" where orderNumber is incremented (in your trade tracking logic of course) and decremented.

Thus if you want the 3rd one in the index, you just say S3 (or maybe S2 if you are going to sync and use S0 as your first order).

By using the array, it gives you the ability to work against the group.

yes, I suppose you could do the same thing and build a list when you need it by looping through open orders or whatever, but it would seem to me that having your array ready to use would be more efficient.

r2kTrader, your approach using a trade class is interesting, albeit somewhat more complicated than I have used to date. Although I do use a Trade() method that can be called by several alternate entry signals and find that straighforward. My strategy is complex enough with IceBerg order quantities, limit orders away from the bid/ask mean, simulated stops of all kinds, and real working stops. I have just started running this strategy live on NT7B4, so time will tell whether improvements are necessary.

I suggest that it is still possible to get enough relevant trade information, when a single string name in the signature, or a single IOrder name is used.

For example the profit for closed trade position pairs can be determined using:
Trade myClosedTrades = Performance.AllTrades[Performance.AllTrades.Count;

Similiarly the unrealised profit and loss for a position on the current bar series for a particular asset can be determined with:
myPrelimTradePL=Math.Round(Position.GetProfitLoss( Close[0],PerformanceUnit.Currency)/Math.Max(1.0,(double)Position.Quantity),0);


You note that with a trade class you can "index .. your trade and thus have complete granular control" However you can get necessary control in other ways in OnExecution() by testing the current execution for desired characteristics such as whether a full fill or a part fill has just occurred and whether to place a stop.

If I get time a may explore using a trade class, but I cannot see as yet how to use to an advantage!

[r2kTrader]

Aussie,

Also, with a trade class, you are talking about 3 or 4 lines of extra code total.

It's much cleaner because once you build your trade helper class, you don't have to look at it anymore. It sits outside of your strategy. You only need to instantiate it and then use it.

[Aussie2]

Trade Class Useful

I agree there is greater flexibility with your suggestion using a trade class. And appreciate the discussion.

My strategy design to date has been based on testing wide bid ask ranges. Placing limit orders further away is on my "to do" list.

My view with stops is that you need to make them sufficiently distant from the relevant entry to let the strategy breathe. This is what my backtesting showed. To solve the stop issue you discuss, with the kind of entries I had, I entered a simulated stop coded in the strategy with any additional lots acquired, and I waited till all orders were filled before entering a final real working stop for all lots a little further away from entry than my simulated stop. This was slightly easier to code in the first instance.

Regards

[r2kTrader]

Aussie,

I like that. It's an interesting way to fade. I was actually visiting the simulated trade and found it pretty interesting. It's quite powerful and ironically, it's under-utilized.