As of RC2 (and possibly since NT1 for all I know) the documentation says
And this means Close[0].
Problem:
When OnBarUpdate() is called in Realtime CurrentBar is pointing to the last closed bar. NT has received the first tick of the next bar (which I call bar-being-built). So the latest price (of the dataseries' MarketDataType) is in GetOpen(CurrentBar+1) but Close[0] might be days out of date (say if market has just opened after a weekend break).
When in Historical the current substitution of the out-of-date Close[0] is causing all sorts of problems. These problems might only be noticed once per day after session break (since intra-day bars usually have no opening gap), so the problems are most noticeable if using a BarsPeriodType.Day datasouce.
Suggested solution:
a) Change the documentation to say something like
b) Change the implementation to use GetOpen(CurrentBar+1).
Here's a quote from Ray (CEO) which backs up what I am saying
What Ray here calls "next bar" is what I am calling "bar-being-built".
If this change is made it should probably be done in the same release as the suggested fix for the problematic 'historic stop order price check rule'. This is because user strategies often use GetCurrentBid() minus some ticks to assign a price for a stop order on a Long (for example), and both GetCurrentBid() and the Historical stop order rule are currently looking at the same (potentially days out-of-date price).
Sidenote:
When accessed during State.Historical, the Close price of the evaluated bar is substituted.
Problem:
When OnBarUpdate() is called in Realtime CurrentBar is pointing to the last closed bar. NT has received the first tick of the next bar (which I call bar-being-built). So the latest price (of the dataseries' MarketDataType) is in GetOpen(CurrentBar+1) but Close[0] might be days out of date (say if market has just opened after a weekend break).
When in Historical the current substitution of the out-of-date Close[0] is causing all sorts of problems. These problems might only be noticed once per day after session break (since intra-day bars usually have no opening gap), so the problems are most noticeable if using a BarsPeriodType.Day datasouce.
Suggested solution:
a) Change the documentation to say something like
When accessed during State.Historical, the Open price of the new bar is substituted.
Here's a quote from Ray (CEO) which backs up what I am saying
Signals are generated on the close of a bar thus the next tick (which is the open of the next bar) is where the order is filled at. Limit and stop orders are "working" on the next bar and evaluated against this bars data to determine if it indeed has been filled and at what price.
If this change is made it should probably be done in the same release as the suggested fix for the problematic 'historic stop order price check rule'. This is because user strategies often use GetCurrentBid() minus some ticks to assign a price for a stop order on a Long (for example), and both GetCurrentBid() and the Historical stop order rule are currently looking at the same (potentially days out-of-date price).
Sidenote:
Ideally GetCurrentAsk() in Historical should be using GetAsk(CurrentBar+1), and GetCurrentBid() in Historical should be using GetBid(CurrentBar+1), but since neither GetAsk() nor GetBid() currently work properly, that’s probably a step too far for now!
Comment