Different behavior of setColorPriceBars(true) and setComputeOnClose() in 11.x

[SteveH]

In 10.6, if I have a script where, in preMain(), I have:

setComputeOnClose();
setColorPriceBars(true);

and, in main(), I go about setting the current price bar color with setPriceBarColor(color, Color.black, true), then current real-time price bar will be the prior bar's color. This is something which goes back 9 years to version 7.9.

In 11.4, if I have the same thing, then the current real-time price bar will be some grey, fat-wick candle until the price closes.

If I exclude setComputeOnClose(), then I've got problems with the current candle keeping the same closing price color as when setComputeOnClose() is in preMain(). If doesn't make sense (to me). You would think that setting the candle color on every tick coming in would wind up giving you the same colored chart as though you had had setComputeOnClose() on the whole time but that's not the case.

I would REALLY, REALLY like the 10.6 behavior back where you don't give me some fat grey candle (if setCompueOnClose() is in preMain()) but rather maintain the color of the previous candle until I set it properly on the close. Why *shouldn't* the current candle BE the prior candle's color in the first place? After all, with setComputeOnClose(), I *should* have control of the current real-time color based on what I said it should be from the last time I set it (on the prior bar's close). [7.9 -> 10.6 got this right, IMHO, something got "fixed" which wasn't broken]

[SteveH]

eSignal Support,

Why is the candle painting logic not backward compatible to 10.6? Even if I use setPriceBarColors(true), using setComputeOnClose(), I should have the current real-time candle color painted what the last one was set as until at least the current candle close where my script logic can set it to something else, not some grey candle with a fat wick.

I am a paying customer who has been patiently waiting for 6 days. Do I need to start making phone calls for this support request? That is far more costly for your time and mine.

[SteveH]

Here is some sample code to show what's happening. The first pic is from 11.5 (Oct 3rd). It will not color the candle to what the prior one was while 10.6 will (imo, 10.6 is correct).

The only workaround in 11.5 is to not have setComputeOnClose(). This introduces computational overhead where it's not wanted or needed. My real script would be doing a lot of unnecessary calcs if I had to turn it on for every tick coming in.

var i = 0;

function preMain()
{
  setPriceStudy(true);
  setColorPriceBars(true);
  setDefaultPriceBarColor(Color.grey);
  setComputeOnClose();
}


function main()
{
  if (i % 2 == 0)
    setPriceBarColor(Color.yellow, Color.black, true);
  else
    setPriceBarColor(Color.cyan, Color.black, true);

  i++;
}

[eSignal_EricL]

This change in eSignal 11 was done at the request of third party vendors with systems that used the setPriceBarColor and setComputeOnClose functions for the signal. They wanted the colors to be applied only to completed bars which when using setComputeOnClose happens only up to the second to last bar. This change has been documented in the EFS Knowledgebase article #2200 since it was implemented.

[SteveH]

Eric,

All you had to do was provide a user-selectable option to color the new way or old. That way, everyone is happy and it doesn't break backward compatibility with 10.x and before.

This was a bad decision. You forced those who disagree with your "3rd party vendor" pressured change now to incur more computational overhead to support the old coloring behavior by having to look at every single tick coming into an EFS.

[It would have been a trivial software change to support both types of candle coloring behaviors. I don't know much, but 2 computer science degrees and 25+ years of software development experience tells me that.]