Does OnExecution have a BarsInProgress context?

[bltdavid]

I know the "BarsInProgress context" for OnBarUpdate can determine which instrument an EnterLong() is submitted for.

For example, this code is from the NT7 help guide,

protected override void Initialize() 
{
    // assume the primary bar series is MSFT on a 1-Minute chart
    Add(PeriodType.Minute, 3);
    Add("AAPL", PeriodType.Minute, 1);
}

I understand how EnterLong() must be implicitly aware of the BarsInProgress context in order
to work properly. Obviously, OnBarUpdate has a BarsInProgress context, for example, this is
from the NT7 help guide,

protected override void OnBarUpdate()
{

    // Checks to ensure all Bars objects contain enough bars before beginning

    if (CurrentBars[0] <= BarsRequired || CurrentBars[1] <= BarsRequired || CurrentBars[2] <= BarsRequired)
        return;

 
    // Checks if OnBarUpdate() is called from an update on the primary Bars
    if (BarsInProgress == 0)
    {
         // Submits a buy market order for MSFT
        EnterLong();
    }
 
    // Checks if OnBarUpdate() is called from an update on AAPL 1 minute Bars object
    if (BarsInProgress == 2)
    {
         // Submits a buy market order for AAPL
        EnterLong();
 
         // Submits a buy market for MSFT when OnBarUpdate() is called for AAPL
        EnterLong(0, 100, "BUY MSFT");
    }
}

My question is: does OnExecution have the same BarsInProgress context as the BarsInProgress context
the order was submitted against?

If the inside of OnExecution references Close[0], there must be a BarsInProgress context for that, right?

Will the BarsInProgress context be for the value barsInProgressIndex if the Advanced Order
Handling method,

EnterLong(int barsInProgressIndex, int quantity, string signalName)

is used for the entry order?

I mean, if I Add() 5 additional time-frames (same instrument) then obviously the BIP used for the EnterLong
all refer to the same instrument -- but the BIP specified in the EnterLong() call, will that exact same BIP
carryover as the "BarsInProgress context" for OnExecution, such that Close[0] references the
correct close price of the same BIP as specified by the EnterLong(BIP, ...) call?

Is the answer the same for OnOrderUpdate?
Is the answer the same for OnPositionUpdate?
Is the answer the same for OnMarketData?
Is the answer the same for both managed and unmanaged mode?
Is the answer the same for both NT7 and NT8?

As you can see, I'm trying to determine how deep and prevalent the "BarsInProgress context" really is,
especially, where it can be relied upon and where it is absent.

Thanks

[NinjaTrader_Jesse]

Hello bltdavid,

does OnExecution have the same BarsInProgress context as the BarsInProgress context
the order was submitted against?

If the inside of OnExecution references Close[0], there must be a BarsInProgress context for that, right?

OnExecution is still part of the class you are working in, BarsInProgress and the other inherited properties would be available in the Class context however these variables really only relate to Bar Processing.

While the overall script does share the inherited base variables, this override is event-driven and is not specifically related to your bar processing which sets BarsInProgress. You can utilize these properties from OnExecution however they are not exclusive to OnExecution like they are in OnBarUpdate. If you are trying to target specific data or BarsInProgress from methods outside of OnBarUpdate, I would suggest that you be specific instead of relying on the script to set the base variables for you. You can use the plural series such as Closes[1][0] in that context to ensure the right price was used for the order it applies to. When not using multiple series, you can feel free to use the inherited variables as you want because they will represent the current state of the only instrument being processed.

Will the BarsInProgress context be for the value barsInProgressIndex if the Advanced Order
Handling method,

Code:
EnterLong(int barsInProgressIndex, int quantity, string signalName)
is used for the entry order?

I mean, if I Add() 5 additional time-frames (same instrument) then obviously the BIP used for the EnterLong
all refer to the same instrument -- but the BIP specified in the EnterLong() call, will that exact same BIP
carryover as the "BarsInProgress context" for OnExecution, such that Close[0] references the
correct close price of the same BIP as specified by the EnterLong(BIP, ...) call?

I believe the above statement covers this as well, you would need to specify which BIP in OnExecution, the BarsInProgress will not carry over specifically. You would not have the same type of if(BarsInProgress == 1) condition inside of OnExecution, you would instead just use the overload you have shown and put 1 as the BIP for EnterLong. Order events are generally tracked by the signal names and this is used to further control logic from this point rather than relying on the bar processing which is no longer relevant to the order.

Is the answer the same for OnOrderUpdate?
Is the answer the same for OnPositionUpdate?
Is the answer the same for OnMarketData?
Is the answer the same for both managed and unmanaged mode?
Is the answer the same for both NT7 and NT8?

Yes, the OnBarUpdate method is really going to be the main method where these inherited/processed variables are relevant. The other event-driven methods which are not specifically for bar processing would be called for other reasons, like how OnExecution is called for executions and OnMarketData is called for market data events. While you can read the inherited/processed variables during one of these events, that would only represent its last known value or the last value processed by OnBarUpdate. In relation to an execution, this may provide enough time between the last bar close and execution event returning to no longer be the same BIP or hold relevance toward the event in OnExecuion. While it is likely the same BIP would be seen in this case, if one of the other series calls OnBarUpdate before the execution returned that is no longer true.





Please let me know if I may be of further assistance.

[bltdavid]

Yes, the OnBarUpdate method is really going to be the main method where these inherited/processed variables are relevant. The other event-driven methods which are not specifically for bar processing would be called for other reasons, like how OnExecution is called for executions and OnMarketData is called for market data events. While you can read the inherited/processed variables during one of these events, that would only represent its last known value or the last value processed by OnBarUpdate. In relation to an execution, this may provide enough time between the last bar close and execution event returning to no longer be the same BIP or hold relevance toward the event in OnExecuion.

Thanks, but I think you misspoke about one thing, let me focus on your last sentence below.

While it is likely the same BIP would be seen in this case, if one of the other series calls OnBarUpdate before the execution returned that is no longer true.

I seem to recall OnMarketData was special, it actually had a real
BarsInProgress context setup when OnMarketData() was called.

This comment seems to imply that OnMarketData is using the "leftover"
BarsInProgress context of whatever happened to have been active
at the moment it was called. I think this is wrong.

Inside OnMarketData, we use BarsInProgress to differentiate the Bars
series, just like for OnBarUpdate -- so doesn't OMD have a real BIP
context, same as the real BIP context for the call to OBU?

While it is likely the same BIP would be seen in this case, if one of the other series calls OnBarUpdate before the execution returned that is no longer true.

I need to comment more on this sentence, esp the "before the execution" part.

At the user level, we are doing event driven programming, we are supplying "callbacks" to the NinjaScript framework,
essentially building a plugin (both indicators & strategies are just plugins) for NinjaTrader.exe to execute.

I think the implication "before the execution" returned here is wrong.

[EDIT: Perhaps I should ask, what do you mean here by "execution"?]

My point is:
In no way will the next OnBarUpdate be called until after the current callback (such as OnExecution
or OnMarketData or OnBarUpdate, et al) returns control back to your framework. Right?

The way I read your answer, I'm think you're implying a multi-threaded callback environment, which is not
what NinjaTrader is. Because NT7 (and NT8, too, I believe) is strictly an event driven framework, we are
not told to expect or be concerned about the simultaneous execution of an OnBarUpdate running at the
same time as an OnExecution, right? We're not using locks or mutexes, so it's not multi-threaded ...

[NinjaTrader_Jesse]

Hello,

It looks like there is a note about this in the help guide for OMD, the BIP can be used for OMD in some cases, however, I would still suggest to just be specific with BIP fields for order entry in OnExecution per your question. As part of your question references other areas of NinjaScript which perform differently all I can really suggest here is to be specific in your development and to not always exclusively rely on the inherited bar processing variables where it is not directly noted to do so in the help guide. Adding additional series is not something which can be done dynamically so the BIP index will always be static for order entry purposes in OnExecution. The BarsInProgress inherited property is not directly used in any OnExecution examples that we provide to give any suggestion that it could be used from this override, however, we do provide samples which use the signal names for completing order logic in OnExecution which is the general suggestion here. Using unique signal names could work as defining constants for specific BIPs in your logic, or more simply it would be assumed you know which BIP relates to the signal name of the order ahead of time. Knowing this would allow other uses such as Closes[1][0] for pricing of a specific series or generally using any other variable which takes a BarsInProgress index. All order entry methods also contain a BIP overload for this use case or where it needs to be specified which series to submit the order to.



Please let me know if I may be of further assistance.