Question about setBarBg - repeated

[mbuta]

This is an example of bad histogram in real time, when I return an already stored array of values.
Please note the price pane in the two charts on the left.


Full explaination can be found in my previous post on the subject.

I made it a new thread because nobody [with EFS engine knowledge] responded.
I hope this will get some attention from qualified support people.

Thank you.

[eSignal_JasonK]

Hello Mihai,

Unfortunately, I'm not completely understanding the problem myself. Based on the code snippet you've posted in this thread, it is inconclusive. Please post a working sample to that thread that illustrates the problem and I'll test it additionally.

[mbuta]

Hi Jason,

This is a theoretical question about how setBarBgColor should work.

The situation id very simple:
a/ Not busy time: I generate some plots and order setBarBg(ymin,ymax) for some or all mplots [irrelevant].
Note: the return array is stored as a global var, every time it is re-calculated.

b/ In busy times: I return the last calculated array, but [of course] I do not bother to order setBarBg.
EFS engine seems to "remember" the previous setBarBg, but does not look at the values in the array [?!?!?!] and colors the entire background.

Even if I post the real code it will be very dificult to reproduce it.

So, the questions are:
1. Why EFS "remembers" setBarBg [in busy times, when not ordered]? and
2. If it does, why does not "remember" the previous ymin, ymax as well? and
3. But, if does not "remember" ymin, ymax, why does not look at the source [my return array].

I hope this is much more clear than a messy script.

Additional note: I also tried to return "null" [no array]. Still same thing.

Thank you

[eSignal_JasonK]

Hello Mihai,

Originally posted by mbuta
Hi Jason,

This is a theoretical question about how setBarBgColor should work.

The situation id very simple:
a/ Not busy time: I generate some plots and order setBarBg(ymin,ymax) for some or all mplots [irrelevant].
Note: the return array is stored as a global var, every time it is re-calculated.

b/ In busy times: I return the last calculated array, but [of course] I do not bother to order setBarBg.
EFS engine seems to "remember" the previous setBarBg, but does not look at the values in the array [?!?!?!] and colors the entire background.

Even if I post the real code it will be very dificult to reproduce it.

The problem is most likely a logic issue that is specific to your combination of code. If the problem does not occur often with your formula in question then the best way for us to investigate the issue would be to test your code on our side. It is understandable if you do not want to post the entire script. If possible, please try to create a copy of the formula and remove the nonessential portions of the formula that continue to display the problem. Comment out small sections at a time and test for the problem after each modification. This process sometimes can lead you to a solution or least point out the problem area of the formula. If you are successful with this and still are not sure what is causing the problem, please post that abbreviated code so that I can investigate this further. If there is a bug here, we'd like to find out what the specifics are so we can get it fixed.

So, the questions are:
1. Why EFS "remembers" setBarBg [in busy times, when not ordered]? and

By design setBarBgColor() does not remember the previous execution regardless if the parameters passed are global variables. The bg color will stick only for the last execution of main() where is was executed. If you have some logic in the code that subsequently prevents setBarBgColor() from executing, then the bg color effect gets removed. The following example illustrates this behavior. Run this in real time. It will color the bg for the first 20 ticks of the bar and then stop executing the setBarBgColor() function from the 21st tick. You will see that after the 20th tick the bg coloring is not applied to the chart.

function preMain(){
    setStudyTitle("test");
    setShowCursorLabel(false);
    
    setStudyMax(100);
    setStudyMin(0);
}

var b = true;
var yMin = 25;
var yMax = 75;
var nCount = 0;

function main() {
    nCount++;
    
    if (getBarState() == BARSTATE_NEWBAR) {
        nCount = 0;
    }
    
    if (nCount < 20) {
        setBarBgColor(Color.maroon, 0, yMin, yMax);
    }
    
    return stochK(14, 1, 3);
} 

Within your formula, if you are still seeing a bg color being applied, it is likley that you have another background coloring call somewhere prior to your busy times logic where you're using setBarBgColor(). Check to make sure you don't have any other calls for this function or setDefaultBarBgColor(). Check preMain() as well and any other user defined functions that you have in your formula that could be making one of these function calls.

2. If it does, why does not "remember" the previous ymin, ymax as well? and

Only setDefaultBarBgColor() would remain applied once called, or remember as you describe it. Are you using this function by chance instead of setBarBgColor()?

3. But, if does not "remember" ymin, ymax, why does not look at the source [my return array].

I hope this is much more clear than a messy script.

Additional note: I also tried to return "null" [no array]. Still same thing.

Thank you

The source of your return array doesn't have anything to do with the functionality of setBarBgColor() or setDefaultBarBgColor(). There isn't anything stored in the return array other than the numbers that you're returning.

Hope this helps.

[mbuta]

Hi Jason,

Thank you for your detailed response.

You confirm what I expected it shoudl hapen: Nothing, unless "ordered.

I re-checked [n's time] the code.
a/ I do not use setDefault...
b/ There is no other setBarBg in my code, except when I construct the return array [in non-busy times].

My "guts" tell me that the problem comes from the inv("1S") series I use to determine the busy times. I did not find an ohter way to determine "busy times" [regardless of time interval or type of security].

I will try to make simplified version of the efs [lazyness is the main reason for hesitation to post it].

Thank you.

[mbuta]

Hello Jason,

I may have identified what generates the problem, but not why it does it.

I ran into an other manifestation [abnormal behaviour when setBatBg(ymin,ymax) was part of the code, although not executed].

In a diferent routine [that for coloring plots Fg] I was using "setDefaultBarFg".

Now, figure this out:
If "setBarBgColor(ymin,ymax)" was part of the code configuration INITIALLY LOADED [I can do that with a main parameter], then all the BarFg colors were shifted one bar, even if subsequently the setBatBg was not part of the code [I can do that with buttons].
If setBarBg was not part of the initial configuration, there was no problem. Coloring was correct.

I changed the setDefaultBarFg into setBarFg and the problem is gone. Remember, this was a completelly diferent routine.

I ran into strange behaviours when using setDefault in main before, so the question I have is the following:

Is it illegal to use SetDefault [whatever, BarBg, BarFg, BarThickness, etc] in main?

Note: I use them to initialize the plots [from main, because the number of plots is variable, so I cannot do it in pre-main].

Note2: If it is not illegal and your team wants a sample code that shows the problem, I will more than happy to provide it.

Note3: If they do look into this problem, I suggest them to look also at why "setPriceBarColor" cannot be used only when needed. That also is "set" at initial load time. If there is used once, then we MUST color all the price bars. It may be the same root cause.

Sincerely,

[eSignal_JasonK]

Hello Mihai,

Originally posted by mbuta
Hello Jason,

I may have identified what generates the problem, but not why it does it.

I ran into an other manifestation [abnormal behaviour when setBatBg(ymin,ymax) was part of the code, although not executed].

In a diferent routine [that for coloring plots Fg] I was using "setDefaultBarFg".

Now, figure this out:
If "setBarBgColor(ymin,ymax)" was part of the code configuration INITIALLY LOADED [I can do that with a main parameter], then all the BarFg colors were shifted one bar, even if subsequently the setBatBg was not part of the code [I can do that with buttons].
If setBarBg was not part of the initial configuration, there was no problem. Coloring was correct.

I changed the setDefaultBarFg into setBarFg and the problem is gone. Remember, this was a completelly diferent routine.

This is most likely a logic conflict in your code. It's not a general behavior that I'm aware of. If you would post a sample that illustrates this, I'd be more than happy to take a look.

I ran into strange behaviours when using setDefault in main before, so the question I have is the following:

Is it illegal to use SetDefault [whatever, BarBg, BarFg, BarThickness, etc] in main?

It is perfectly legal.

Note: I use them to initialize the plots [from main, because the number of plots is variable, so I cannot do it in pre-main].

So, you are dynamically changing the size of the return array with a function parameter? This could be the culprit for the logic conflict. Make sure that in main() you have some logic that prevents any setDefault... calls from being executed for a return index that is not being returned. For example, don't execute setDefaultBarBgColor(Color.blue, 3), if you are only returning 2 series.

[QUOTE] [B] Note2: If it is not illegal and your team wants a sample code that shows the problem, I will more than happy to provide it.

It is legal. However, we'd still like to see a code sample so that we can uncover what the problem is. If there is some bug here, we'd like to get it fixed, but we need to be able to reproduce it.

Note3: If they do look into this problem, I suggest them to look also at why "setPriceBarColor" cannot be used only when needed. That also is "set" at initial load time. If there is used once, then we MUST color all the price bars. It may be the same root cause.

Sincerely,

This has been discussed already actually, but is not a high priority to change right now. It is something we will revisit in a later version.