Close Value On Bar Zero.

The close value for bar 0 is not finalised until that bar is . . Closed, and at that point it becomes Bar 1. Close[0] = Bid

RaptorUK,

Thank you for your response. Though when the bar has been completed shouldn't MetaTrader pick up the last tick for the bar? I am speaking in context of the strategy tester.

When bar[1] closed, and closed on close[1], the next event at bar[0] is open[0]. not close[0].

So you cannot perform this comparison of equals, i.e cant take close[N+1] "ties-up" close[N]. It surprised me mad that you mentioned

Which instrument is that is what really like to know from you. Thx.

Ticks are driven by movement of price, if the price stays the same, e.g. over the weekend, there are no ticks. A H1 bar ends at 59 mins, 59.9999 sec past the hour, but if price doesn't change during the last minute of the hour there will be no ticks during that last minute. The only time when you know the final value for Close[0] is when it becomes Close[1]. It's no different for the Strategy Tester, although the ticks are synthesised based on volume, more volume=more ticks. The best you can do it detect the first tick of Bar 0 and then used the Close of Bar 1.

RaptorUK,

I understand what you are saying but this significant price change between hours in the middle of the week is a little different. Why doesn't the iClose() use logic such as..... if the time of the last tick is > the time of the previous tick, use this value for close. In other words, you are not needing to look for the opening of bar[1] to finalize the close price. To word it differently, the last tick to arrive would the the last tick representing the last price or potentially the close price for the bar. I have read in another posting that the system does not use the last tick for determination of the closing price as it is related to iClose(). I need to do my homework to find out how to get the last tick price. I will post my findings.

That is what happens . . . the question you need to answer is . . "which tick is the last tick" ? ticks do not arrive governed by time, they arrive when price has moved . .

Ok, thanks.

RaptorUK,

I spent most of this morning working on a program that gives me ticks and volume. What I discovered is that there is a delay as you stated between receiving ticks from the quote server. As a result of this delay, you may not receive the last tick or a number of ticks within a one minute bar. Since bar pricing is associated with a tick, you may not get an accurate close price.

So now the question is, what is causing the tick delivery delay. Is the situation related to an overburdened quote server such that there is latency in delivering quotes on time to each client terminal? There could also be latency due to price quote data (data packet) problems in delivery over the internet. Though, if this was the case, you would still receive all of the data packets, they would just be late in arrival.

By any chance, could it be that the client terminal drops the tick update if it is too late in arrival? In other words the client terminal has moved on from bar[0] to bar[1] so it is too late to update bar[1] as it has already closed? The last tick obtained becomes the final tick recorded?

This seems logical to me because if the program continued to update previous closed bars with late data packets, historical volumes would be in flux.