drawTextPixel()

[wildfiction]

I use this function to draw a button in the bottom left corner of my chart. I call the function once during the initialization code and often the button remains there for the whole trading day.

However, sometimes it dissappears. I think this happens when I scroll backwards through the data and load new data into the chart.

Andy ideas?

drawTextPixel(ButtonLeft, ButtonBottom, " XXX @URL=EFS:drawXXX", 
                null, null, Text.BUTTON | Text.RELATIVETOLEFT | Text.RELATIVETOBOTTOM,
                 null, 10, "XXX"); 

[eSignal_JasonK]

Hello wildfiction,

Images and text object will be removed when a reload of the chart or a request for more data occurs. So depending on how your code is controlling the drawing functions they may not always be redrawn. For example, if you use a global flag that only allows the object to be drawn once during initialization, the global flag will not be reset when the chart requests more data, but the images will still get removed. There's a few options you can use to get around this.

var bInit = false;

function main() {
    if (bInit == false || getBarState() == BARSTATE_ALLBARS) {
        drawText....
        bInit = true;
    }

    ....
    ....
} 

This one should do the trick. To go one step further you could look for BARSTATE_NEWBAR instead. Give this a try.

[wildfiction]

For example, if you use a global flag that only allows the object to be drawn once during initialization

That's exactly what I was doing.

the global flag will not be reset when the chart requests more data, but the images will still get removed.

Makes sense.

There's a few options you can use to get around this.

var bInit = false;

function main() {
    if (bInit == false || getBarState() == BARSTATE_ALLBARS) {
        drawText....
        bInit = true;
    }

    ....
    ....
} 

Interestingly this worked for 2 "Receiving..." scenarios and then stopped working. So what I did was to redraw the botton when getBarState() == BARSTATE_ALLBARS and while panning backwards through the chart I see the cursor window saying "Receiving", the button dissappears and then comes back again.

Continue to do this and it works on the second "Receiving..." as well and then it ceases to work anymore and the button is gone.

I can't seem to find the logic behind this...

This one should do the trick. To go one step further you could look for BARSTATE_NEWBAR instead. Give this a try.

This works but gives me 2 concerns:
1. What if there is a long pause since the "Receiving..." of back data was received and the next NEWBAR - say several minutes. Doesn't that mean that there will be no button during this period while we wait for this condition to redraw the button?
2. We are trying to conserve every ounce of processor power and most of the time this function is called in this scenario we are doing so uneccessarily and wasting processor time.

Thanks for your ideas - your help is much appreciated.

[eSignal_JasonK]

Hello wildfiction,

This works but gives me 2 concerns:
1. What if there is a long pause since the "Receiving..." of back data was received and the next NEWBAR - say several minutes. Doesn't that mean that there will be no button during this period while we wait for this condition to redraw the button?
2. We are trying to conserve every ounce of processor power and most of the time this function is called in this scenario we are doing so uneccessarily and wasting processor time.

1) That is correct.
2) To reduce the amount of processing in the EFS during the request or reload you could add another layer to the condition to only allow the redraw to occur at bar index of 0 and NEWBAR.

function main() {
    if (getCurrentBarIndex() == 0 && getBarState() == BARSTATE_NEWBAR) {
        drawText....
    }

    ....
    ....
} 

You could also use the time functions, hour(), minute() and second() and only allow the redraw to occur at certain times if you don't want to do the redraw at every new bar.

[wildfiction]

Thanks Jason - I'll try and vary the combinations and see how they work over the coming weeks - thanks for your help.

[Guest]

Guy,

Another option is to left doubleclick the chart to prompt a reload.

function onLButtonDblClk( barIndex, yValue) {
 debugPrintln("2: DoubleButtonClickAction == TRUE");
//go reload your button command here
} 

I believe Jason's suggestion will solve your problem. If most of this post wasn't already completed earlier today, I probably would not have posted this. However, since I already spent my time answering your question, and you had not indicated whether Jason's suggestion had solved the issue you were having, I thought I would post it anyways, as it may help you, or someone else with similar problems.

Without seeing your code, my suspicion is that you are using a standard binit if statement where binit is a global value. When you load more data up by left scrolling through the chart, only the main section of the code is re-executed. If you had your button drawn in the binit section, this section is not re-run.

You can see this by running the following efs:

//Testing what happens when by S. Hare 5/20/2005
function onLButtonDblClk( barIndex, yValue) {
 debugPrintln("3: DoubleButtonClickAction == TRUE");
    reloadEfsFunction(); //testing reload efs function
//go reload your button command here
}
debugPrintln("7: OUTSIDEMAIN == TRUE");

function preMain(){
    setPriceStudy(true);
    setShowTitleParameters(false);
    setStudyTitle("reload efs test");
 debugPrintln("13: PREMAIN == TRUE");
}
var bInit = false;
function main(){
    if (getBarState() == BARSTATE_ALLBARS) {//true once during initial load and subsequent reload
 debugPrintln("18: BARSTATE_ALLBARS == TRUE");
    }
    if(bInit == false){
 debugPrintln("21: binit == TRUE");        
        bInit = true;
}
    if (getBarState() == BARSTATE_NEWBAR) {    
        barcount = getCurrentBarCount();//new in EFS2
    }
}
function postMain() {
     debugPrintln("29: POSTMAIN == TRUE");
}

function reloadEfsFunction(){
    debugPrintln("33: prior to reload efs == TRUE");        
    debugPrintln("");        
    reloadEFS();
    debugPrintln("36: after reload efs step == TRUE");        

} 

here is the output to the debug window:

7: OUTSIDEMAIN == TRUE
13: PREMAIN == TRUE
18: BARSTATE_ALLBARS == TRUE
21: binit == TRUE
18: BARSTATE_ALLBARS == TRUE
18: BARSTATE_ALLBARS == TRUE
18: BARSTATE_ALLBARS == TRUE 

Steps 7, 13, 18 and 21 are executed when the efs is installed. The next three instances where step 18 executed occured when I was scrolling back in the chart and more data was loaded. If you want your button re-drawn automatically, I would recommend you put the command in the BARSTATE_ALLBARS section

[wildfiction]

Originally posted by stevehare2003
here is the output to the debug window:

7: OUTSIDEMAIN == TRUE
13: PREMAIN == TRUE
18: BARSTATE_ALLBARS == TRUE
21: binit == TRUE
18: BARSTATE_ALLBARS == TRUE
18: BARSTATE_ALLBARS == TRUE
18: BARSTATE_ALLBARS == TRUE 

Hi Steve,

Many thanks for the help and you're little test program: Very useful to give an insight into the ALLBARS.
Also the double click is a good idea for an efs reload to save time.

Your debug output that you've quoted here is from top down. Have you just done that for convenience in this post or is there an option in eSignal to make the debug output print top down instead of bottom up?

Thanks again.

[Guest]

Guy,

You are welcome. As you indicate, the debug output is written to the screen bottom up, with the most recent output on the top. All I did is go to the C:\Program Files\eSignal folder and open up the formulaoutput.log file. This file is where the formula output window is written to (it has to go somewhere).

Even if you clear the debug window in the eSignal session by right clicking the the debug window and selecting clear, or from within an efs using the debugClear() command, the output sent to the file stays intact. The file is overwritten only after you re-start eSignal, something that can come in awfully handy if your efs is crashing eSignal and you want to figure out the last command that is successfully executed (using debugPrintln() ) before it crashes.

Regarding the doubleclick to reload the efs, while I included it in the sample efs to perform an efs reload, my intention (for your post) was that the doubleclick be used to re-load the button commands. Using the reloadEFS() may not be the best solution (as Jason indicated in another thread) since it does not execute the entire efs, which can by itself cause problems. Similar to the behavior seen when scrolling back and the chart loads more data, only the main() section of the code is re-run, and not the if(bInit == false){ conditional, preMain() , etc. So if you are using the reloadEFS() command to solve something, make sure you have all of the necessary elements of your code executing when this option is selected.

[wildfiction]

Thanks for the info Steve - as always very useful for now and future reference.

What does the reloadEFS() function do exactly?

and what undesirable behavior can it cause?

This function forces the current EFS script to be reloaded by the chart. Note that the values set in any variables external to the main() function will be preserved during the reload process. Use this function with caution as it can cause undesirable behavior.

Is there a way to programmatically force the same behavior as right click: Reload -> Study.efs ?

Thanks

[Guest]

Hi Guy,

If you play around with the efs I posted, perhaps modifying it by adding some global values and modifying the global values in different sections, the particulars of the different methods of reloading the efs will become apparent to you.

What does the reloadEFS() function do exactly?

It starts your efs by loading all the bars again, not re-setting anything in premain or outside main.

and what undesirable behavior can it cause?

If your efs is dependent on resetting variables outside main to function correctly when all bars are loaded, and you use the reloadEFS() command to re-load all the data points (without provisions to reset the afore mentioned variables defined outside main), your efs will not function correctly. A simple example is where you initialize barcount outside main as a global variable set to zero. Inside main, you increment the barcount variable by one every newbar. Each time you reload the efs you will continue to increase the barcount. I would solve this by using the new command made available in EFS2:

barcount = getCurrentBarCount();.

This would ensure your barcount was accurate during a reloadEFS() command.

Is there a way to programmatically force the same behavior as right click: Reload -> Study.efs ?

Not 100%, however you can get close by doing something like this:

    if (getBarState() == BARSTATE_ALLBARS) {//true once during initial load and subsequent reload
        Initialize_efs();
    } 

I use the Initialize_efs() function to reset all required variables (as I deemed to be required).

Hope this helps.

[wildfiction]

That helps a lot Steve, thanks for all your advice. I'll get playing with those optioins.