Execution update event can not trigger after entry order fill...

[NinjaTrader_JessicaP]

I am happy to answer questions from the NinjaScript documentation. I do need to mention that if we are no longer examining the NinjaTrader platform itself, and our goal is now getting your code working correctly, that fully debugging and developing user code is beyond the scope of the support we may provide. If you would prefer start-to-finish help that ends with your code working the way you would like please let us know so that we can put you in touch with a NinjaScript consultant.

To answer your questions directly, OnExecutionUpdate is called once every order successfully executes. The entryOrder object is your way to tell execution.Orders apart. This handle to your order is set immediately when you place your order, and is nulled when your order has been filled.

If you are noticing a difference in behavior between execution.Order.Name == "Entry Order" and execution.Order == entryOrder, the most likely reason for this is that your entryOrder object is being overwritten. That is,

• You set entryOrder to order A with the name "Entry Order"
• You set entryOrder to order B with the name "Entry order"
• Order A executes

[aytacasan]

I'm not happy Jessica. For a month i sent several code examples to support forum. And i used continuously same code lines for open pending orders like below;

Managed => entryOrder = EnterLongLimit(...);
Unmanaged => entryOrder = SubmitOrderUnmanaged(...);

Neither you nor others not warn me about that "your order can execute before set to your variable, be careful about that". Also your user guide not warning about that. Oh i see this is not scope of support and it's scope of debug process or this is not so important thing for warning, isn't it? I don't think so.

Anyway i'm only happy about that finally i can develop the strategy without contact any consultant and it's working correctly even suffer a little bit.

Also I need to mention that if we are no longer examining the NinjaTrader platform itself, it's evolution will stop. For example i'm still waiting your answer about my #3 post (http://ninjatrader.com/support/forum...04&postcount=3), is there any progress about it?

My words not for your personality, i'm talking generally about NT's support team.

[NinjaTrader_JessicaP]

Our team, myself included, pride ourselves on good service, and if you can let us know how we can improve I will make sure to pass on any feedback to the rest of the team. We want you to have the best experience we can provide.

This said, I want to make sure the advice I gave when I addressed your questions regarding entry orders was given with me on the same page. I want to be sure, when you mention variables not getting set before an execution, do you mean that myOrder in a call like this,

[FONT=Courier New]Order myOrder = EnterLongLimit(Close[0] + TickSize * 3);[/FONT]

would be set to null? If this is not what you meant, please let us know. If it is, the reason I did not give you any warnings like you specified - and in fact gave this advice

If you are noticing a difference in behavior between execution.Order.Name == "Entry Order" and execution.Order == entryOrder, the most likely reason for this is that your entryOrder object is being overwritten. That is,

• You set entryOrder to order A with the name "Entry Order"
• You set entryOrder to order B with the name "Entry order"
• Order A executes

Is because this should never be the case, and if this actually occurs this is a bug. A valid test for this bug would be

[FONT=Courier New]
Order myOrder = EnterLongLimit(Close[0] + TickSize * 3);
Print(myOrder != null ? "PASS" : "FAIL");[/FONT]

It is much more likely the case that you are setting myOrder twice. What can happen, in addition to the scenario I outlined before, is that if you are reusing handles between orders, another order can nullify your handle.

If a test like the one I outlined in this post fails, please let us know. Otherwise we can safely assume you are being immediately returned a handle to your order.

With regard to post #3, there have been several improvements to the playback functionality in recent versions of NinjaTrader. We need to first make sure that you are using version 8.0.5.2 . You can see which version of NinjaTrader you are using in Help -> About . You can download the latest version of NinjaTrader from ninjatrader.com .

Once we are on the latest version, please follow the instructions in this video and let us know what your results are.

https://www.screencast.com/t/Ww7uQ7WY

[aytacasan]

Hello Jessica,

Maybe problem is my high expectations from your support. I'm using NT for develop and test scripts which are my customers requests. Because of that i'm interesting supporting by you from scripting perspective. And always assume support team have better knowledge and experience versus me because they are concentrate only NT platform (i'm trying to support my customers for many platforms) and they have a chance to contact development team. When i ask a question to support, i don't like to see this words "i don't know", "i don't aware" etc. If so, let the other colleague response my request. This is only an example. Also sometimes i see you or your colleagues responding very fast but don't try to understand fully what is the problem.

For example in my #3 post's article 5, i'm saying that problem occur when u use more then one price panel on the same chart. But u are using one chart & one price panel when u prepare a video about market replay(talking about your #18 post's video link).

Another example in this post from your response i understand; you are saying that your entry order handle may reuse or setting null by other entry order condition and your logic about order execution can fail. But you know that i'm using 8 tick renko chart on ES (8 tick so big for low volatile instrument ES) and looking 64 ticks renko for trend direction. What i mean is send entry order frequency very low and when you look at my example code;

1. There is no way to send second before entry order handle return null state.
2. Only way to set entry order handle to null is fully fill current order.

If so your suggestion/warning not make sense for me (even so thanks for your warning). Above i'm talking exactly about that. You didn't understand me correctly and talking about that not related subjects with my problem. Lets return my problem.

1. There is GLOBAL variable entryOrder
2. Before test entry condition first i'm checking entryOrder handle, if it's not null doing nothing because this mean there is an working order and/or it'is not fully filled yet
3. If entryOrder handle is null so we can try to enter a new position and if entry condition is true i'm setting entryOrder handle with NT's order submit functions (for example EnterLongLimit). Code is somting like that entryOrder = EnterLongLimit(...);
And yes i test it via Print function like your said and write below code very next line; Print(entryOrder == null ? "entryOrder is NULL" : "entryOrder is NOT NULL"); Never printing "NULL" and this is expected behaviour. So problem must be happening between this lines because also i'm writing same Print line in order execution method. After check output window i see something like that;

>>> Entry Limit Order Sending... (Before line entryOrder = EnterLongLimit(...); in OnBarUpdate method)
>>> entryOrder is NULL (Very first line in OnExecutionUpdate method)
>>> entryOrder is NOT NULL (After line entryOrder = EnterLongLimit(...); in OnBarUpdate method)
4. When entryOrder handle returning null state? After cancelled, rejected or fully filled my entryOrder, otherwise strategy doing nothing, can not sent any same or opposite direction order. (Cancelled&Rejected status are handling inside OnOrderUpdate, Filled status is handling inside OnOrderExecution)

And please read this lines carefully; when i notice about this problem is most important thing. I do many market replay tests without any problem thousands orders open/close successfully. After download one plus month for test i see some orders for new month's data not working successfully. So i see (i think) when EnterLongLimit function lines processing, OnExecutionUpdate can be work before set entryOrder handle. Because of that if (entryOrder == execution.Order) { } failing and stopLoss and takeProfit orders can not be sending and position will be open forever.

For solve this problem, i don't set entry order handle with return of submit order method and only call the method, i mean not used entryOrder = EnterLongLimit() instead only call the method EnterLongLimit(). And i changed my code inside OnOrderUpdate for guarantee to set entryOrder handle before any execution;

		protected override void OnOrderUpdate(Order order, double limitPrice, double stopPrice, int quantity, int filled, double averageFillPrice, OrderState orderState, DateTime time, ErrorCode error, string comment)
		{
			if (order.Name == "Long Entry" || order.Name == "Short Entry")
			{
				entryOrder = order;
				if (entryOrder.OrderState == OrderState.Cancelled || entryOrder.OrderState == OrderState.Rejected)
				{
					entryOrder = null;
				}
			}
		}

Because, order process cycle in NT, order execute must be work after order update method. So entryOrder will be set prior to execute an order. And this is fixing my problem.

About my #3 post (market replay problems); thanks for video but i'm already using 8.0.5.2 64 Bit version and about my problems nothing changed (i don't do test for all issues). First please don't forget that NT is one of the top five platform in the world in my opinion and i like it. NT that without any bug/problem and more featured that makes me happy. But sad to say that NT8 have many bugs and of course i'm not satisfied about that. Almost every week i'm notice new bug and because of that don't have to time and tire to report, no longer reporting. For example this week's bug is in market replay mode, if i open 2 chart (same instrument but different time frame);

1. Click second chart's "Show Data Box", after appear DataBox move your mouse on historical bars (on same chart) you'll see data will be change on DataBox as expected.
2. Click first chart's "Show Data Box", after appear Data Box move your mouse on historical bars (on same chart) you'll see data will not change on Data Box.

This is my opinion; NT is not a small company so it must have test team for test your platform. But your test team is so lazy or they didn't test enough because of limited time schedule.

Thanks,
Aytac

[NinjaTrader_JessicaP]

I appreciate your feedback and will definitely keep it in mind as we go further. I do want to make sure that I am giving you useful advice. Sometimes we do simplify situations from those we are given so that we can isolate individual things that are occurring from a series of interlocking behaviors, especially when users mention potential bugs, as these necessitate our separating what you as a user can control from behaviors only accessible to the platform in order to be able to address these queries. For this reason I would like to suggest that techs will have an easier time giving the best possible service if we create separate threads to report separate behaviors, and simplify situations as much as possible. Regardless, we will always try to deliver the best service we can, and we appreciate your advice regarding us slowing down and ensuring the test scenarios we use match yours. I will continue working past our communications barriers, and if I post any simplified scenarios designed to zero in on one behavior or another I will make sure to explicitly explain any differences between what you are suggesting and what I am posting in the future.

I wanted to make this post separately from my reply addressing your queries directly. Thank you again for using NinjaTrader 8, and for your assistance improving both our platform and our service.

[NinjaTrader_JessicaP]

This said, let's zero in first on your entry order behavior. When we can resolve this query, let's then move on to improving your playback connection. For now, if I am not addressing your questions regarding the playback connection, this is why, and I would like to assure you these are not being ignored.

User code not working as expected is something beyond the scope of the support we can offer directly, and we can not consider situations like this to be bugs. Due to this, I am going to provide a sample from the help guide. This gives you and I a situation we can examine in which any behaviors we discover that turn out to be bugs can be immediately corrected, which is power and flexibility we would not enjoy if we were working with user submitted code. Any incorrect behavior with respect to the sample code I provide can safely be considered as a bug without any work separating userspace causes from intrinsic-to-ninja causes.

[FONT=Courier New]//http://ninjatrader.com/support/helpGuides/nt8/en-us/onorderupdate.htm
private Order entryOrder = null;
 
protected override void OnBarUpdate()
{
  if (entryOrder == null && Close[0] > Open[0])
      EnterLong("entryOrder");
}
 
protected override void OnOrderUpdate(Order order, double limitPrice, double stopPrice, int quantity, int filled, double averageFillPrice, OrderState orderState, DateTime time, ErrorCode error, string nativeError)
{
  // check if the current order matches the orderName passed in "EnterLong"()
  // Assign entryOrder in OnOrderUpdate() to ensure the assignment occurs when expected.
  // This is more reliable than assigning Order objects in OnBarUpdate, as the assignment is not guaranteed to be complete if it is referenced immediately after submitting
  if (order.Name == "entryOrder")
      entryOrder = order;
 
  // if entry order exists
  if (entryOrder != null && entryOrder == order)
  {
      Print(order.ToString());
      if (order.OrderState == OrderState.Cancelled)
      {
          // Do something here
          entryOrder = null;
      }
  }
}[/FONT]

We see in the above code sample an important difference with respect to the user code you have submitted :

From the help guide :

[FONT=Courier New][B]if [/B](entryOrder != null && [B]entryOrder == order[/B])[/FONT]

In your code :

[FONT=Courier New][B]entryOrder = order;[/B][/FONT]

This means that you are not using entryOrder in a manner it was intended to be used. The reason for keeping an entry order reference is to be able to distinguish a particular order from others that are in process during OnOrderUpdate. When you say

2. Before test entry condition first i'm checking entryOrder handle, if it's not null doing nothing because this mean there is an working order and/or it'is not fully filled yet

This is not what is happening. You are, instead, forcing your entryOrder handle to adopt whatever value order has without checking it. It is true you are checking its name, and this check would fail with a runtime error if it was null, which is a sort of null check. However, as the sort of check you are performing will cause your strategy to switch off prematurely, you are advised instead to perform the kind of checking recommended in the help guide.

If, in the sample code I provided, the order object (that is, the one called 'order') is ever null, this situation would be a bug. Likewise, if you are not including code such as that I have highlighted from your code sample, and your entryOrder is nulled sometime between placing the order and the beginning of OnOrderUpdate (before any code is added or executed in the OnOrderUpdate method body), this situation would also be a bug.

Otherwise it needs to be pointed out that OnBarUpdate and OnOrderUpdate are completely asynchronous. This is why the help guide includes an explicit null check - again for reference,

[FONT=Courier New]if ([B]entryOrder != null[/B] && entryOrder == order)[/FONT]

You are correct that OnOrderUpdate can occur between two lines of code in OnBarUpdate. If this fact was not made clear to you as a user, I will let the product management team know and work with them to better explain the asynchronous nature of NinjaTrader. I would ask that you review this help guide page, and that any suggestions you have regarding how we can better prepare users for this situation treat this page as a starting point.

http://ninjatrader.com/support/helpGuides/nt8/en-us/multi-time_frame__instruments.htm

Of special interest is the "True Event Driven OnBarUpdate() Method" section. Other event methods such as OnOrderUpdate are truly event driven as well.

Please let us know if all of our queries regarding execution updates have been resolved before we investigate the playback connection.