Edit:
I just realized that every time someone creates a 1 tick chart and expect to see each tick and its volume is getting false graph in NT8. That is a serious bug! Did you implement the tick bars in the same way in NT7? If so I need to disqualify my tick research there too
(2) Tick replay, in the case you are using "Bid"/"Ask" data, should not provide false "Last" events. Or it should show the real tick type ("Bid"/"Ask") or it shouldn't show these events at all.
Think about it, a developer is making an indicator that calculates bid or ask data for plotting purposes, which has to rely on volume that appears in OnMarketData, and in real time it fills the values correctly (differing "Last", "Bid" and "Ask" events) and when calculating historically, all OnMarketData events are "Last" (Which includes "Bid" and "Ask" events among them).
This means that you are blocking any development that can utilize Tick Replay in case the developer is using data other than "Last" in his indicator/strategy.
Why not do the easy thing which is fixing the problem (=False event types in OnMarketData)?
I am not bothering you because I like it. I am a developer that has to stop his Tick Replay based development because of false event types.
I tried bypassing the bug with getting the "BarsInProgress" number from the OnBarUpdate and by knowing the number I can know the real event type that follows in OnMarketData. But after you answered me in (1) that there are ticks that you miss in OnBarUpdate because of same ms timestamp it eliminates this bypass method.
If you are not going to fix the bug anyway please help me understand how to bypass it when I am using 3 tick based data series:
AddDataSeries(base.Instrument.FullName, Data.BarsPeriodType.Tick, 1, Data.MarketDataType.Last); AddDataSeries(base.Instrument.FullName, Data.BarsPeriodType.Tick, 1, Data.MarketDataType.Ask); AddDataSeries(base.Instrument.FullName, Data.BarsPeriodType.Tick, 1, Data.MarketDataType.Bid);
Comment