OnExecution Method

[mjuviler]

Hi,

I am having an issue with getting the correct number of Filled Contracts in OnExecution.

My understanding is that execution.order.filled will return the actual number filled, not the original order size.

So if I buy 11 contracts @ Market in a thin Market (dec Gold ZG) for instance the order is likely to be filled in pieces, like so

3 Filled
5 Filled
2 Filled
1 Filled
-----
11

FYI: The fills are shown correctly in the Control Center Executions tab

Each fill generates a call to the OnExecution Method correctly (4 times)

The problem is that execution.order.filled always returns 11 (even though only 3 are initially filled the first time in, 5 the second time, etc)

FYI: execution.order.quantity always returns 11 as well.

This is really throwing off my code because I need to update the stop as the order gets filled.

Thanks for any help on this. BTW this happens live trading and in replay.

Here is a snipet of my code

protectedoverridevoid OnExecution(IExecution execution)
{
//Always prints 11 for above example
Print("execution.Order.Filled: " + execution.Order.Quantity);

if ( (StopOrder != null && StopOrder.Token == execution.Order.Token) )
{
if (execution.Order.OrderState == OrderState.Filled || execution.Order.OrderState == OrderState.PartFilled)
{
PositionQty = PositionQty - execution.Order.Filled; //always subtracts 11

[NinjaTrader_Ray]

This is a multi-threaded environment --> You can not count on the order filled amount being in sync with the executions in fact --> Do not code in a way that would expect this.

It may work for some brokers may not for others, it may change. What you can count on is that OnExecution() will give you all executions and OnOrderUpdate() will give you all order state changes.

[mjuviler]

Ray,

Thanks....

But I am confused.

I know it is multi-threaded, that is why I love OnExecution because whenever there is an execution it will drop into OnExecution.

In my previous example OnExecution was called 4 times for the Buy 11 @ Market.

I am not relying on anything in particular, I would just expect that if I identify the Order Token (which I do) then execution.order.filled would show the correct number based on the reason NT was calling my OnExecution method in the first place.

What is the point of execution.order.filled if it does not hold the number filled for this multi-threaded call into onexecution?

Thanks for helping me understand....

MArk

[mjuviler]

Ray,

One more thought.

From your ref samples you say:

"The OnExecution() method is updated whenever you receive an execution or a fill on your orders. This method provides you the fastest possible submission of protective orders. Utilizing the increased granularity provided in these advanced methods can be advantageous to you by providing you with maximum control of how your stop-loss and profit target orders behave."

How can I control my stops and targets if I don't know how many contracts are filled?

Mark

[NinjaTrader_Ray]

Execution events are asynchronous to order state events from most of the API's we write to. For the most part, we pass through these events and the order object that is associated to the execution will have information up to date from the last time NinjaTrader received an event for it.

To the question of knowing how many were filled --> You do know this since we are providing you with this information. You could for example hold an internal counter that is set to 11 when you submit the order and subtract from that as execution method is called.

Another option which I am am checking into still is seeing if the taking the filled amount will work as expected with partial fills. So, if you had 11 partial fills but on the first execution event, the underlying order object was already filled 11, you could just send the stop through. This is how the reference sample is coded and I sent a note to development to ensure this in fact will work as expected. I expect an answer by tomorrow morning.

[mjuviler]

Thanks Ray I appreciate your assistance.

Let me know what Development says.

BTW I notice that the latest release of NT from the other day (6.10005) has a new Zen Fire API that was coded for.

Can you tell me what and why that was done? Is that the latest version of Zen Fire's API? What was the reason for this upgrade on this release of NT? Is this a major improvement in some way?

I am interested because I am running some serious customer money in automated futures strategies using NT with Zen-Fire (from Mirus).

Thanks....

Mark

[NinjaTrader_Dierk]

>> What was the reason for this upgrade on this release of NT? Is this a major improvement in some way?
No particular one. There is no particular ZenFire issue addressed.