Alert.addToList problem ...

[eSignal_JasonK]

Hello George,

The vFlag variable I used in the code example is the method you need to incorporate to stop the "flooding." Make sure the setCompute feature is unchecked, or set to false. You may need to use several flags, one for each different condition. When the condition for the alert first occurs, allow the code block to execute and then set it's flag inside the code block to "true." In your if statement that checks for the alert condition, add " && vFlag == false" to prevent the code block from executing subsequent times during the same bar. Then add a routine to the top of your formula that resets your flags at the instance of a new bar like I've done in test1.efs using getBarState(). Test the code examples I gave you and you'll see the behavior. The alert condition will only occur once per bar, which I think is what you are attempting to achieve. Correct?

[wombat953]

The alert condition will only occur once per bar, which I think is what you are attempting to achieve. Correct?

Jason - this is exactly correct.
I appreciate your assistance, and am getting back on the case.
Thanks
George

[wombat953]

Jason
I have incorporated the changes, and it appears that the CurrBarIndex is never zero, so the second "if" is never true, and no function call is ever issued. So, no colorful backgrounds and no Alerts.
Here is the complete code(not executable without another efs, or changing lines 167-168 (to true and false, respectively).
I don't know how to format it more nicely.......

function Buy() {  
ticksize=callFunction("FunctionLib.efs","getTicksize",getSymbol());
var stopIn = (high(0)+ticksize);
var stopOut =(Math.min(low(0),low(-1))-ticksize);
    if (getBarState() == BARSTATE_NEWBAR) {
        vBuyColor = null; 
        vBuyFlag = false;debugPrint("A"+crlf," currbarindx = "+getCurrentBarIndex());
    } //end if
        
    if (getCurrentBarIndex() == 0 && vBuyFlag == false) { debugPrint("B"+crlf);
        var Buy_Mess = star+currBarDate+star+currBarTime+star+getSymbol()+" Bar "+getCurrentBarIndex()+colon+
        "BUY STOP "+getSymbol()+At+formatPriceNumber(stopIn)+", Protective SELL STOP "+At+formatPriceNumber(stopOut);
        vBuyColor = callFunction("FunctionLib.efs","BuyMessage",Buy_Mess,getSymbol(),currBarTime);
        vBuyFlag = true;
    }   //end if
/*BuyMessage(Buy_Mess,getSymbol(),lastAlertTime,curBarTime);*/
if (vBuyColor != null) setBarBgColor(vBuyColor);
return 
} 

Here is the function:

function BuyMessage(Buy_Mess,symbol,currBarTime){
            var lastBuyAlertTime;
            setBarFgColor(Color.black,0);setBarFgColor(Color.black,1);
            setBarThickness(2,0);setBarThickness(2,1);/*setBarBgColor(Color.green);*/
            var vBuyColor=Color.green;
                //debugPrint("curr = "+currBarTime+" Alerttime = "+lastSellAlertTime+crlf);
                debugPrint(Buy_Mess+crlf);
                Alert.addToList(symbol,Buy_Mess, Color.green, Color.black );
                /*Alert.playSound("cashreg.wav");
                Alert.email(Buy_Mess)*/
return vBuyColor; 
} 

[Doji3333]

A little help is needed...

Wombat...

Got your files and am trying to make sense of it...

First off, there are errors in the Backtest file (that I am fixing).

Were you able to get this working at all?? If so, can you attach the file you have that works...

If not, then these errors are probably what is causing the problem. I will try to assist you by cleaning up the file.

Brad

[Doji3333]

Possible solution...

Wombat,

Here is the *potentially* debugged "backtest" file..

BRad

[wombat953]

Brad - in the attached zipfile, ##shorter_term.efs and FunctionLib.efs are the only ones pertaining to this thread. The correct ones are timstamped 6:33pm.

This is the implementation of the first two parts of the Elder Triple Screen system from Trading for a Living book. I have written separately to Brad re whether or not the eSignal Backtester supports the third screen (which requires STOP LIMIT order types). Garth Doverspike has helped me code the backtesting version that I have at this point, but it stops short due to the question I just raised.

the "backtester is a more complex animal than the one attached here in that seeks to to implement backtesting of efs in multiple timeframes. To backtest, I need to do some other things, such as save the "longer term" values to a file using Tools, Data Extract, and read them in with the "shorter_term" efs , correlate with the longer term file values, etc.....This bypasses the separate "longer_term" efs concept, which uses values available from a file, rather than the global var. pool.

And yes, yes, we got it working..perfectly...it does (in "batch") what cannot be done after market close, which is to recognize trends from a longer term interval (dumped to flat file), and identify overbot/oversold conditions within those longer term trends. Red or green bars - as appropriate are drawn, and Alerts issued. The system requires setComputeOnClose (or simulation thereof).

But I don't want to clutter this problem I am having. I have attached only the two relevant files. I hope the attach feature is working....

We can talk about the other matter over on:

http://forum.esignal.com/showthread.php?s=&threadid=3424

Thanks
George

[Doji3333]

I hope I fixed it...

I don't believe Alerts will be issued for past (historical) bars, so (to the best of my ability) I have corrected the code to allow for it to work in RT.

I have also added a few things to force it to react (for testing purposes)..

Line 51 - forces the vBuyFlag and vSellFlag to false.

Lines 93 and 114 - replicate the alert for the buy and sell signals.

Lines 197 and 201 are the MAIN alert system calls.

Line 190 forces the system OUT OF the BARSTATE routine.

Misc corrections to function definitions, brackets ( { and } ).

I can't guarantee this is perfect, but I believe it will work for you.

You can uncomment line 172 to see it force an alert into the system, but this was just a test.

I have gone through most of the code to make sure every line functions properly. This way, we can be sure nothing HALTS the system from operation.

I also removed the unnecessary "return" values from your functions. If, within a function, you change or set a global variable, you don't need to then RETURN it to the main function.

I hope this helps..

Brad

[wombat953]

Brad - that is great. I will check it out right now. Are you saying that no changes are need in the called function (in the FunctionLib.efs), but only in the "calling module"?
Thanks
George

[wombat953]

Brad - I have implemented this code with Tools, Settings, ComputeOnClose not checked, which I believe is the default. It is also the recommendation of most of the Moderators here. This was the source of my initial problems.

What is required to simulate it(setComputeOnClose), such that Alerts, etc. are not issued multiple times within the same minute, or even second? I am unable dump (copy/paste) the Triggered Alert List, but it appears that Alerts are still being triggered even within the same second (to the degree the generated times are accurate).
What I had before, with setComputeOnClose enabled, was a signal (Alert) only at the completion of a bar, and it is this that I am striving for. The bar was cut, the chart background and foregrounds colors changed, and the Alert object was triggered, be it to the screen, sound or email.
Perhaps I want to replace the rawtime logic with every chart interval (getInterval()), or similar(like BARSTATE)????
Thanks
George

[wombat953]

Jason - I am sorry. I cannot seem to implement this.
Can you pls add the appropriate statements into the efs, below?
Note that I have a "main", which invoke a "Buy", which invokes a "BuyMessage", the last one being in a separate library. I have added the return of the color, that you mentioned, to the BuyMessage in that library.

You can test it by replacing the following lines 167-168:
UpTrend=getGlobalValue(UpVal);
DownTrend=getGlobalValue(DownVal);
with UpTrend=true;
DownTrend=false
This avoids having a separate module (which I have) to pass those values to the global variable pool. I have spent many hundreds of hours on this, and my Alerts - which actually tell me what to do - seem to fail because of this undocumented Alert shortcoming when setCompute etc. is set.
Thanks
George

[Doji3333]

George...

I just turned on the code to check it today. I had not had a chance to do anything to it today.

I took care of the code issuing multiple alerts on a single bar with my "Bar Time Checker". So this should not be a problem.

I just have to watch it to see what is happening with the code.

Brad

[wombat953]

Brad - what is ""Bar Time Checker""?
George

[Doji3333]

George...

Just got my first alerts with your Short Term code...

It generated 2 alerts, but that was because my code told it to generate two alerts..

So, I believe my code is working for you.

Brad

[wombat953]

Brad - do you have current version please?
George

[Doji3333]

Here you go...

George...

Here you go.. This is the version that I am running..

My "Bar Time Checker" is on line... 190

Still generating 2 alerts for each instance of your system, but that can be resolved by removing one of the alert calls.

Brad