getBarState not working!!!

[arbifox]

Anyone else have a problem with the following function? This used to work for me, but is failing in E-Signal 7.1 for some reason. Anyone have something simple to replace it that works in 7.1 and 7.2?

FUNCTION:
getBarState() == BARSTATE_NEWBAR

Thanks,

Thomas.

[gspiker]

Hi,

If you mean:

if (getBarState() == BARSTATE_NEWBAR){
<do something>
}

then I would have to say no. It has functioned correctly in every release, prerelease, beta and prebeta that I have tried.

Garth

[arbifox]

I will check it again . . .

Maybe something is hosed on my install, but I know for a fact it is not working, and now I need it to work right. I will look at it some more and check it out.

Thanks, T

[gspiker]

If you narrow it down to a small test sample that doesn't work, feel free to send it to me and I will see if it has the same problem on my system.

Garth

Thomas,

Here is a method used by Brad Matheny to test for new bar formation. I have been using and it works well.


//Testing for the current bar…
If (getCurrentBarIndex() == 0) {
// Do something
}
//Testing for a new bar formation (using the "time" of the bar)…
// First, declare a global variable to keep track of the last "time" of the previous bar(s).
var nLastRawTime;
If (getvalue("rawtime",0) != nLastRawTime) {
// New Bar - so do something
nLastRawTime = getvalue("rawtime",0);
}

[gspiker]

I don't think that will really tell you when a newbar is formed...at least not in realtime. Since the only things that determines NEWBAR is a difference in this interation of EFS's rawtime to the rawtime the last time the EFS was called. Clearly if we are dealing with 1 hour bars, the time will change MANY times (possibly for each tick that comes in, though with a one second granularity on rawtime it might take a few ticks to increment rawtime values).

I think you might have left something out on the way Brad does this, or you are only worried about historic bars (in which case this method will work well).

G

rawtime

Check the link below regarding rawtime usage, below that is an excerpt from the link. When I first saw this in use, my thoughts were similar to yours...please try it and test it with debug, it works very well in RT code!

Steve

rawtime usage, guidance to Developing eSignal Indicators


Coding examples:


Testing for the current bar…


If (getCurrentBarIndex() == 0) {

// Do something

}



Testing for a new bar formation (using the “time” of the bar)…



// First, declare a global variable to keep track of the last “time” of the previous bar(s).

var nLastRawTime;



If (getvalue(“rawtime”,0) != nLastRawTime) {

// New Bar – so do something



nLastRawTime = getvalue(“rawtime”,0);

}

Written by Brad L. Matheny for eSignal, A division of Interactive Data Corporation, November 2002.

[gspiker]

Verrry Interesting. You learn something new all the time (and if your lucky, you don't have to pay for it).

I ran a simple test (see attached if you are interested) and indeed the method does work. The next question is why, and as it ends up getValue("rawtime"); doesn't work the same way getValue("time"); does (as initially advertised). rawtime only returns the time at the start of the bar.

This has implications for a few formula's I have seen out there that assumed rawtime was just a lightweight version of time.

Thanks for pointing this out...it will save me some time as I had it on my slate to covert some of my EFS's from time to rawtime - but now know it will not work for me.

Garth

[arbifox]

I knew it

something was just not right, I have been using my own flavor, but an EFS developed by TSS which worked months ago stopped working. That is how I stumbled into this whole mess. Thanks for checking up . . . I will take some of the suggestions and look them over.

T

getCurrentBarIndex() functionallity

Garth,

I took your file, ran it, and noted that once the history info was processed, the different methods came up with different results. Specifically, while running overnight on the emini, sometimes getCurrentBarIndex() returned a zero several (between 2 and 10 times) while getValue("rawtime",0) and getBarState() == BARSTATE_NEWBAR did not. I have attached a small notepad file showing the output. I expected them to fire once each at the beginning of every bar, but this result was not expected. Can you please take a look and let me know if this is consistent with your understanding of how this works and let me know what you think?

I also attached a copy of a modified version of your efs that I used to generate the file for your info.

Thanks,

Steve:

p.s. I'm having problems attaching multiple files, I'll repost if they both do not show up

Garth,

Here is the efs file I discussed in the previous post.

Steve

[arbifox]

Something is still off . . .

Folks,

Something is still not right, let me explain a little more.

I have an EFS, and first it will will run on all historical data. When those bars are processed, they have to be handled a little differently then once we catch up to the present point in time. This is because I use my own logic to effectively backtest, otherwise results are very skewed.

I used to use a 60-minute bar, so I would distinguish the change of the bar by the hour being different then the previous tick. Now I use a 3-minute bar, so I suppose I have to try something on the minute level.

The getcurrentbarindex does not work the way that it should according to my logic, since it will not show a different state on the first tick of a newbar. It will just show 0 if we are on the current bar.

I suppose what I need is to know what is the very FIRST tick of a bar, and I thought that was done by the:

getBarState() == BARSTATE_NEWBAR

function, but alas, we are then full circle since that does not work all the time. I will code my own function, but it would be nice to have something that works regularly.

Thomas.

[JayF]

Just a quick note I'm moving this thread to the EFS Studies forum as the content is more suited to that forum.

[gspiker]

Steve,

Sorry for the slow reply, up to my ears in alligators here (how they got to Seattle I'll never know).

getCurrentBarIndex should return zero when we are processing the last bar in a chain of bars. It will return 0 for each tick in that last bar. Once a new bar starts, the old bar 0 will now be bar -1 and the new bar is bar 0, and for each tick that comes it you should get a current bar index of 0. So it should be possible to get many 0 returns with this, for each NEWBAR.

Since rawtime only reports the time at the start of the newbar, it should report the same time for the entire bar, and only change once a NEWBAR happens. This means it does basically the same thing as getCurrentBarState. Useing the rawtime method does add a bit of extra processing time, but hardly worth mentioning (1 extra system call).

So the results you are seeing makes sense to me, unless you are running on a very large interval chart...in which case I would expect more 0 returns for the emini than you are seeing, even during off hours.

G

[gspiker]

Thomas,

Did you try to run my test code? Did it not show a NEWBAR for each NEWBAR that came in?

There used to be a problem (and may still be, I haven't really tracked this), that a bar wouldn't be painted unless there was a trade executed during that interval. Could it be that you are seeing a 3 minute interval pass without a trade, and therefore to your code it looks like getBarState() isn't working?

Just shooting in the dark here. Again, if you can create a simple case that shows getBarState() not working I'll take a look at it using the interval(s) and symbol(s) you specifiy and see if I see the same problem, and if I do if I can figure it out. If this is a bug, it will be the simplest way to get eSignal to fix it also...because that way they have a simple test case to use to reproduce...

Garth