Counting wins and losses

[sgordet]

I'm finding that if I place an order for 200 shares of stock and the broker fills it in two separate 100 share lots; when closing, it's counted as two wins or two losses. Is there any way around this?

Here is representative code

if(Performance.RealtimeTrades.WinningTrades.Count >= 2 ||Performance.RealtimeTrades.LosingTrades.Count >= 2)
{
Do something
}

[NinjaTrader_RyanM1]

Hello sgordet,

The simulator will look at real time bid / ask volume, so ultimately there will need to high enough volume to fill it all at once.

There is a setting you will want to check through, under tools > options > Simulator tab > make sure Enforce partial fills is unchecked.

If this is live trading, unfortunately there's no way in NinjaTrader to flag an order as fill or kill. Your fill quantities are based on market dynamics.

[sgordet]

1. If the broker breaks up my order into separate lots can I still count on OrderState.Filled to tell me that the order is completed or is the order itself somehow broken into separate orders?
2. SampleCancelOrder uses OnExecution to trigger stoploss orders. I'm not understanding why a filled state isn't a filled state and OnExecution is needed. Could you explain?
3. Am I correct in thinking that if I place stoploss and target orders in Initialize() that are tied to named entries, I don't need any of these OnExecution/OrderState checks, that once the order is filled the tied exits are automatically executed as appropriate?
4. I'm confused about OnOrderUpdate. It's called every time there's an order update and I can check for an OrderState; however, it seems to me that some of the order states overlap, e.g., OrderState.PendingCancel would also be an OrderState.PendingChange. Are all order states submitted sequentially so that only one order state exists at a time, so that, for instance, a PendingChange would happen and then a PendingCancel so that either of the order states could be checked for?

[NinjaTrader_RyanM1]

1) This sounds like a partial fill scenario and there is a separate order state for this.
OrderState.PartFilled.

2) This section excerpted from our help guide below explains why OnExecution() is needed.
If you want to drive your strategy logic based on order fills you must use OnExecution() instead of OnOrderUpdate(). OnExecution() is always triggered after OnOrderUpdate(). There is internal strategy logic that is triggered after OnOrderUpdate() is called but before OnExecution() that can adversely affect your strategy if you are relying on tracking fills within OnOrderUpdate().
• As an example, the NinjaTrader core may have received "Working" and then "PartFilled" order state change events back from the broker API on thread "B" and at some point in time (milliseconds later) the NinjaTrader core will take these events and trigger the OnOrderUpdate() method in the strategy on thread "A". Thus, when the strategy receives the first "Working" state for an order, the IOrder object passed in will reflect the "Working" state although the actual order is really in a state of "Part Filled" which is truly reflected in the original IOrder object returned in any of the order methods such as EnterLong(). Of course, the OnOrderUpdate() method will subsequently receive the event for "PartFilled" state.

3) Yes, Set orders are automatically submitted upon entry execution. This is done internally in the platform and not something you have to code for.