main called on BARSTATE_CURRENTBAR *and* _NEWBAR for same tick?

[tinker70]

I have two areas that I think I understand, but want to make sure.

1. In streaming mode, suppose we've already caught up with the historical bars. A tick comes in to start a new bar, so eSignal calls my main() with BARSTATE_NEWBAR. Now, eSignal will not also call my main() again for that same tick with _CURRENTBAR, correct? It will call main() with _CURRENTBAR for subsequent tick data, though.

2. When in BARSTATE_CURRENTBAR, does close(0) give me the price data of the tick? If not, what does?

Thanks.

[ACM]

Re: main called on BARSTATE_CURRENTBAR *and* _NEWBAR for same tick?

tinker70

1. In streaming mode, suppose we've already caught up with the historical bars. A tick comes in to start a new bar, so eSignal calls my main() with BARSTATE_NEWBAR. Now, eSignal will not also call my main() again for that same tick with _CURRENTBAR, correct? It will call main() with _CURRENTBAR for subsequent tick data, though.

That is correct. You should be able to easily verify this using a script similar to the one provided in this article on getBarState() in the EFS KnowledgeBase

2. When in BARSTATE_CURRENTBAR, does close(0) give me the price data of the tick? If not, what does?

Yes it does
Alex

Originally posted by tinker70
I have two areas that I think I understand, but want to make sure.

1. In streaming mode, suppose we've already caught up with the historical bars. A tick comes in to start a new bar, so eSignal calls my main() with BARSTATE_NEWBAR. Now, eSignal will not also call my main() again for that same tick with _CURRENTBAR, correct? It will call main() with _CURRENTBAR for subsequent tick data, though.

2. When in BARSTATE_CURRENTBAR, does close(0) give me the price data of the tick? If not, what does?

Thanks.

[tinker70]

Thanks. After using BARSTATE_NEWBAR a little, I wanted to ask a follow-up if I may.

1. While processing historical bars, the BARSTATE_NEWBAR values for open/high/low/close for the current bar (0) are for the entire bar/interval. But when processing during real-time, the BARSTATE_NEWBAR values for o/h/l/c for the current (new) bar are simply that of the tick that started the new bar, yes? (And the o/h/l/c values for bar index 0 all equal each other, of course, because we're starting a new bar.)

2. What's the approved solution for knowing, inside BARSTATE_NEWBAR, whether the bar we're looking at is historical or not? If the o/h/l/c values for the current/new bar differ, then it's historical (i.e., not real-time, not streaming). But if they're the same, the bar could still be historical. Or have I missed something basic (always a good possibility!)?

Thanks.

tinker70

[ACM]

tinker70

1. While processing historical bars, the BARSTATE_NEWBAR values for open/high/low/close for the current bar (0) are for the entire bar/interval. But when processing during real-time, the BARSTATE_NEWBAR values for o/h/l/c for the current (new) bar are simply that of the tick that started the new bar, yes? (And the o/h/l/c values for bar index 0 all equal each other, of course, because we're starting a new bar.)

That is correct

2. What's the approved solution for knowing, inside BARSTATE_NEWBAR, whether the bar we're looking at is historical or not? If the o/h/l/c values for the current/new bar differ, then it's historical (i.e., not real-time, not streaming). But if they're the same, the bar could still be historical. Or have I missed something basic (always a good possibility!)?

Different OHLC values at BARSTATE_NEWBAR do not necessarily mean that the bar being processed can only be an historical bar. It could be the current bar which is already evolving in real time. Conversely same OHLC values at BARSTATE_NEWBAR do not imply that the bar is the current bar. It could be an historical bar in which those values are simply the same
Anyhow you can determine if the bar being processed is the current bar by using either isLastBarOnChart() or by evaluating if its bar index is equal to 0.
You may want to review the Beginner Tutorial 4: Understanding Bar State and Bar Indexing which I believe explains this in detail
Alex

Originally posted by tinker70
Thanks. After using BARSTATE_NEWBAR a little, I wanted to ask a follow-up if I may.

1. While processing historical bars, the BARSTATE_NEWBAR values for open/high/low/close for the current bar (0) are for the entire bar/interval. But when processing during real-time, the BARSTATE_NEWBAR values for o/h/l/c for the current (new) bar are simply that of the tick that started the new bar, yes? (And the o/h/l/c values for bar index 0 all equal each other, of course, because we're starting a new bar.)

2. What's the approved solution for knowing, inside BARSTATE_NEWBAR, whether the bar we're looking at is historical or not? If the o/h/l/c values for the current/new bar differ, then it's historical (i.e., not real-time, not streaming). But if they're the same, the bar could still be historical. Or have I missed something basic (always a good possibility!)?

Thanks.

tinker70

[tinker70]

Alexis, thanks again. I had already pored over that tutorial, and it makes no mention of isLastBarOnChart(). I do see it in the kb, and that should do the trick; thanks.

Anyhow you can determine if the bar being processed is the current bar by using either isLastBarOnChart() or by evaluating if its bar index is equal to 0.

Re. checking to see if the index is 0: I thought (incorrectly) that the 'current' bar you're processing (whether in BARSTATE_NEWBAR or BARSTATE_CURRENTBAR ) always had an index of 0. Thanks for pointing this out.

Thanks again.

tinker70

[ACM]

tinker70
You are welcome
Alex

Originally posted by tinker70
Alexis, thanks again. I had already pored over that tutorial, and it makes no mention of isLastBarOnChart(). I do see it in the kb, and that should do the trick; thanks.


Re. checking to see if the index is 0: I thought (incorrectly) that the 'current' bar you're processing (whether in BARSTATE_NEWBAR or BARSTATE_CURRENTBAR ) always had an index of 0. Thanks for pointing this out.

Thanks again.

tinker70