stevehopwoodforex.com
https://www.stevehopwoodforex.com/phpBB3/
Print view

Adding indicator calls to my shell EA's
https://www.stevehopwoodforex.com/phpBB3/viewtopic.php?t=4519		 Page 1 of 3
Author:  SteveHopwood [ Sat Nov 28, 2015 4:03 pm ]
Post subject:  Adding indicator calls to my shell EA's
This thread is inspired by LittleCaro's request for help at http://www.stevehopwoodforex.com/phpBB3 ... 29#p131729

In it I shall show how I add calls to indicators to my shells and use them to direct the ea's behaviour. I shall use the "StepMA new 1.05" indi that LittleCaro is battling with to show the steps I take, first of all with the indi as LC wants to use it, then adding a higher time frame call, then adding one of the standard indi's that ships with Empty4 - our old and much loved friend, Stochastic. I have altered the indi colour code so that a red line means sell and green means buy. You will find the shell EA files at http://www.stevehopwoodforex.com/phpBB3 ... ?f=15&t=79

Understand these thingies guys. I am a professional pianist, not a professional programmer. I present here my way of doing stuff. It is not the best way. It is not the only way. Proper Coders here doubtless smile upon my efforts as does an indulgent parent smile upon the efforts of their offspring when attempting a skill that they mastered long ago. Indeed, much of my success as a coder depends on contributions made to it by the Proper Coders over the years - you will see my acknowledgements in the code. It is the way I have devised over the last decade to create EA's easily, quickly and safely. Adopt it if you like it; ignore it if you do not.

In my mind, we have three kinds of indicators:
  • those that are sent with Empty4. These have their own inbuilt calls, for example: CCi has iCCI; moving averages have iMA.
  • 'Custom' indicators. They are indi's written by other coders that usually just wrap up a couple of the standard indicators, add a few pretty colours, the occasional arrow and alert, and pretend to be something clever. The data they hold is accessed via the iCustom call. These custom indicators fall into two categories:
    • the wonderful pieces of work created by the top coders here at SHF. They are a joy to work with. Heave a huge sigh of relief when you find that the custom indi you are including in your ea is coded by one of these people, and enjoy writing the code.
    • the moronic lumps of bollocks created by coders who clearly lack firing synapses. When they are not bollocks, it is because they are total bollocks. They are often a nightmare to deal with and so are labled Crap Custom Abortions.
I shall reference Crap Custom Abortions as CCA from here on. The indi we are dealing with here is a CCA. Happily, it is one of the more benign members of its breed, and so gives up its information more easily than some.

What follows is a description of how I add indi's to my shells to create EA's. It is not the only way. It is not even the best way. It is what I do; it works; it is simple.

In the next post I shall describe how indicators store data and present a representation of that data on our charts.


:xm:
Author:  SteveHopwood [ Sat Nov 28, 2015 4:39 pm ]
Post subject:  How indicators store data
Indicators store data in 'buffers'. There used to be just 8 of them, numbered 0 to 7 so indis were limited in the information they could make available to EA's. Nowadays there are umpteen - certainly more than even the most insane of CCA coders could possibly want.

Drag "StepMA new 1.05" onto your chart and open the Data Window (ctrl + D). You see basic candle information that changes as you hover the mouse over different candles.

You also see three fields
  • 2stepMA(x,x,x) where x represents the three most important input values.
  • Value 2
  • Value 3
These are the buffers that the indi uses to store its data. Buffer indexing starts at 0 so:
  • 2stepMA(x,x,x) is buffer 0
  • Value 2 is buffer 1
  • Value 3 is buffer 2
I wonder what kind of cretin thought up a system that dimwitted. Hey ho.

My next step is to find out if it is possible to drag useful information out of the blasted CCA. I describe how I do this in the next post. For now, just accept that in the StepMA CCA:
  • buffer 0 holds the line price.
  • buffer 1 tells the ea whether the line is red or green.
  • buffer 2 does bugger all.
Working out which buffer provides which information can be a toil. Here it is easy. Hover your mouse over a candle where the line is red and you will see a price in the Value 2 field. Hover it over a green portion and you will see no price in the Value 2 field. The ea interrogates the indi's buffer 1; it finds a price - the line is red at that point; it finds no value - the line is green at that point. Light bulbs are already going off in LittleCaro's head.

For a perfect representation of brilliantly informing coding, repeat the above exercise with HGI. That made the coding a doddle.

When a buffer holds a price, its own code tells it what to do. In this case, it prints a red or blue dot. Other indi's might print an arrow and so on. If a buffer does not hold a price, the indi code tells it to print nothing unless being empty itself has meaning to the indi as is the case here.

It helps to have the source code because that makes working out which buffer holds which data much easier. People often only have the compiled code and then it is a question of trial and error. I describe how I go about it in the next post.


:xm:
Author:  SteveHopwood [ Sat Nov 28, 2015 5:36 pm ]
Post subject:  How I work out if a CCA can be used by an EA
An EA interrogates a CCA with an iCustom() call.

The first thing I do is use my Experiments script to see if useful info can be dragged kicking and screaming from the CCA. It is attached and goes in your Scripts folder. No particular reason for calling it 'Experiments' - just did years and years ago and continued using it ever since. All of my coding conventions developed this way.

I code Experiments so that the code can be quickly and easily copied across to my shell ea. Download the script and open it in your code editor.

Note the commented out line 10:
//#property show_inputs
This prevents the inputs being shown when I drag the script - makes using it quicker. Remove the // if you want to see the inputs when you run the script.

Look at line 12
extern ENUM_TIMEFRAMES TradingTimeFrame=PERIOD_CURRENT;

PERIOD_CURRENT is a CrapQl4 'constant'. I love 'constants'. These look like variables but have a fixed value. PERIOD_CURRENT will hold the value of the current chart, and so strictly speaking is a variable I suppose. Don't care. PERIOD_M15 holds the value 15. PERIOD_D1 holds the value 1440. It is possible to define our own constants and my shells make great use of this, but more of that later.

I discovered ENUM a few weeks ago. It is glorious. In my head, this stands for 'enumerate'. By presenting the TradingTimeFrame as a member of the ENUM group, I present the user with a list of alternatives that cannot be inappropriate. Type ENUM into your editor and run help on it to see the extensive list of inputs this can cover.

My shells use TradingTimeFrame and all candle /indi values/times etc use it to allow the user to change time frames without disturbing the bot. I use it in this script so that I can code the calls to the indi in a way that is easily copied into the ea.

The iCustom call consists of:
  • the chart symbol
  • the required time frame
  • the indi name without extension
  • a list of parameters that match those that the indi shows in its inputs window
  • the buffer the ea is interrogating
  • the candle shift relative to the current candle. 0 = now; 2 = the close 2 candles ago etc
We need a list of inputs in our ea that matches those of the CCA. Look at line 14+ in the Experiments script code (line 1 here):

Code: Select all

extern string StepSet = "------- STEP MA SETTINGS --------";
extern double   StepSensitivity        = 0.12;        // Sensivity factor (higher -> more senzitive)
extern double   StepSize           = 1;          // Constant step size
extern int      StepShift              = 0;          // Shift
extern ENUM_APPLIED_PRICE StepPrice = PRICE_TYPICAL; // Price to use 
/*
We do not need these externs, and will send 'false' as every parameter
extern bool     alertsOn           = false;      // Turn alert on?
extern bool     alertsOnCurrent    = true;       // Alerts on current bar?
extern bool     alertsMessage      = true;       // Show popup message
extern bool     alertsSound        = false;      // Play alert sound
extern bool     alertsEmail        = false;      // Send email
extern bool     alertsNotification = false;      // Send notification
*/
I copied this list from the CCA and added the 'Step' bit to the externs that I allowing the user to see, just in case another indi has an input such as 'Shift', to differentiate between them.

I have gradually learned over the years, from the Proper Coders here at SHF, to make code as reusable as possible. My iCustom call is contained within the function beginning at line 30 in the source code (line numbers shown here are different):

Code: Select all

double GetStupidStep(string symbol, int tf, double sensi, double size, int sshift, int ap, int buffer, int shift)
{

   /*
   Passed parameters:
      - symbol = chart symbol
      - tf = time frame
      - sensi = StepSensitivity
      - size = StepSize
      - sshift = StepShift
      - ap = StepPrice
      - buffer = the indi buffer being interrogated
      - shift = the candle shift to the left relative to now. shift = 0 means now. 
                shift = 4 means 4 candles ago etc
   */
   
   return(iCustom(symbol, tf, "StepMA new 1.05", sensi, size, sshift, ap,
          false, false, false, false, false, false, buffer, shift));
   
  
   
}//End double GetStupidStep(string symbol, int tf, double sensi, double size, int sshft, int ap, int buffer, int shift)
My use of 'string symbol' makes this function more easily portable into a multi-pair ea. Adopt it and you will quickly find your fingers typing double val = Getxxxx(Symbol()........) automatically.

My coding convention is to precede any function that calls and indi with 'Get'. That way I know where to find them. Press Alt + M in your code editor to see a list of functions; clicking on them will take you straight to the code. There are only two script functions, but my ea's contain umpteen.

You can see in the commented out (grey) section of code what each passed parameter represents. The power of taking the trouble to spell out the parameters will become apparent when I add a higher time frame function to the EA.

Now I have my list of extern inputs and a function that will return a value from the indi in a variety of ways, so now we come to how I interrogate it.

Code: Select all

void OnStart()
{

   //Declare a shift variable to make experimenting with the calls quick and easy
   int shift = 0;
   
   //Buffer 1 is empty when the line is green, so find out what value it returns.
   //This will either be zero or the EMPTY_VALUE constant 2147483647 
   //The current line on my chart is green.
   double val = GetStupidStep(Symbol(), TradingTimeFrame, StepSensitivity, StepSize,
                              StepShift, StepPrice, 1, shift);
      
   Alert("Value of buffer 1 when green = ", val);
   
   //This cca uses EMPTY_VALUE, so now check that buffer 1 holds a price when it prints brown.
   //The line was brown 8 candles ago on my chart.
   shift = 8;
   val = GetStupidStep(Symbol(), TradingTimeFrame, StepSensitivity, StepSize,
                              StepShift, StepPrice, 1, shift);
      
   Alert("Value of buffer 1 when brown = ", val);
   //Interrogating the buffers returns usable values, so we can use the cca in an EA
   

}
I am referring now to line numbers in the source code, not as shown here. The OnStart function begins at line 57. I already know that buffer 1 holds a price to give a red line, and is empty for a green line. I have in front of me a chart where the line is currently green.

Line 61 declares shift as 0 so I am looking at the current candle. Line 66 sends a call to the CCA which shows me both that the buffer is empty and what it holds when empty in the Alert that is sent at line 66.

I can see that the line was red 8 candles ago, so line 73 sets shift to 8, line 74 makes the call and the Alert fired at line 77 confirms my assumption.

The reason for the Alert showing the empty field value is this: CCA coders use two methods:
  • filling it with 0.
  • filling it with EMPTY_VALUE.
EMPTY_VALUE is a constant with the value 2147483647. It is a price that no market can ever reach. Coding an EA, I need to know which method the ea coder uses to indicate an empty buffer. Trust me guys; when dealing with really badly coded CCA's, some will use both methods so I need to check all fields.

You can see from the comment at the end of the script that the CCA is usable within an EA. My next post will describe how I port the code across to the shell ea.

:xm:

Edit 4th October 2016:
Bruce contributed the attached indi. Details in his post here: http://www.stevehopwoodforex.com/phpBB3 ... 36#p147136


.
Author:  SteveHopwood [ Sun Nov 29, 2015 12:08 am ]
Post subject:  EA naming conventions
A quick aside here folks.

Anyone who has ever coded EA's understands this basic and inalienable fact: give an EA a crappy name and it will fail.

So, if we call our EA here, "An auto-trader using the StepMA CCA to indicate trade direction" it will descend into chaos immediately.

Instead, it will be called, "Steppy". Granted, this does not guarantee success but neither does it consign it to immediate failure. The CCA consigns it to ruin eventually, so no need to saddle it with a lousy name to destroy it the moment we load it onto our charts.

Never lose sight of this fact folks. StepMA, or whatever the silly thingy is called, is bollocks. I am merely teaching you here how to incorporate bollocks into your EA's. Up to you whether you figure that this turns your EA's into bollocks.

:xm:
Author:  SteveHopwood [ Sun Nov 29, 2015 10:17 am ]
Post subject:  Setting up the EA
I set up my EA once I know I can drag usable information from. These are the steps I follow:
  • Open the shell I want to use. For Steppy I am using Bugger All Included for simplicity.
  • Rename the shell by Files/Save As
  • Define my constants.
  • Copy my externs from my Experiments script and add the extra variables I know I will need.
  • Copy the relevant code from my Experiments script into ReadIndicatorValues().
  • Add code to DisplayUserFeedback() to confirm that the values Steppy is using are correct.
  • Go back to ReadIndicatorValues() and add the code that spots buy or sell signals.
  • Go to LookForTradingOpportunities() and set up the trade trigger code.
  • Add relevant code to CountOpenTrades and LookForTradeClosure().
  • Any tidying up needed.
I shall take all this one post at a time. Next up is defining my constants.

:xm:
Author:  SteveHopwood [ Sun Nov 29, 2015 1:44 pm ]
Post subject:  Defining my constants
You might want to re-download the shells if your previous download was before the date stamp on this thread. I have added to them and use some features new to Steppy.

I have attached Steppy. I suggest if you are new to all this that you use the Bugger All Included shell and add the code as you read through these posts - you will learn more that way. Steppy is here in case you get into a mess. There may be a few bugs - that is not the point of all this. I am doing the coding on a Saturday and the bot runs in code-testing Crapergy Tester, so the basics are pretty much ok.

Back to writing the code. I know how I am going to code spotting the CCA colour change because I have thought about it, and the variables I shall use are standard for me. I just want a few constants so that I do not always have to remember strings such as, "The CCA has turned green".

I define constants and declare variables at the top of the file - constants first, then externs and associated variables. That is just my way. I know where to look for them. Other coders define variables etc above the function they are associated with. It is purely a matter of choice.

We define constants with the key word #define i.e.
#define red " The line is red"

Note the lack of "=" and finishing ';'. We are defining a constant not writing a code snippet. The compiler will whinge about the constant being empty if you forget and add either of these.

I have these constants at the top of the file, just above "pending trade price line."

Code: Select all

//Declare some colour constants for the crap custom indi colours.
//They are brown for sell and green for white on my chart.
#define  green ": Green"
#define  red ": Red"

//Declare some colour constants for the crap custom abortion change status
#define  allgreen ": All green"
#define  allred ": All red"
#define  justturnedgreen ": Just turned green"
#define  justturnedred ": Just turned red"
There is nothing special about my use of lower case letters. They just make typing quicker a little further down the line.

I have declared two new sets of variables at the end of the "General inputs" section:

Code: Select all

//Variables to tell the ea that it has a trading signal
bool           BuySignal=false, SellSignal=false;
//Variables to tell the ea that it has a trading closure signal
bool           BuyCloseSignal=false, SellCloseSignal=false;
These are in the updated shells, so add them if you are using one of the older ones.

Next comes setting up the CCA inputs and variables.

:xm:


.
Author:  SteveHopwood [ Sun Nov 29, 2015 1:58 pm ]
Post subject:  Adding the chart feedback.
The chart feedback is not for the benefit of users. It is for my benefit. When some idiot posts, "It dunt wurk", I can tell him I am not a mind reader and to post a pic. The chart info often sends me in the right direction to find what is not working, or to fry his balls in batter if he is merely a cretin unable to be bothered to read and follow basic instructions.

Go to the DisplayUserFeedback() function (remember, Alt + M will show you a list of functions and clicking on one will take you there).

Scroll down a few lines until you get past:

Code: Select all

if(!TradeTimeOk)
   {
      SM(NL);
      SM("----------OUTSIDE TRADING HOURS. Will continue to monitor opent trades.----------"+NL+NL);
   }//if (!TradeTimeOk)

   SM(NL);
Copy this snippet:

Code: Select all

   SM("Step MA values" + NL);
   SM("    " + StepMaColour[2] + StepMaColour[1]
      + ": Colour change status" + StepMaChangeStatus
      + NL);
   string text = "No trade signal";
   if (BuySignal)
      text = "There is a buy signal";
   if (SellSignal)
      text = "There is a sell signal";
   SM(text + NL);
Run the EA and you will see some of the information that the snippet will provide once Steppy has read the CCA.

Next up: reading the CCA

:xm:
Author:  SteveHopwood [ Sun Nov 29, 2015 2:15 pm ]
Post subject:  Reading the CCA
I put calls to indicators into ReadIndicatorValues(), so go there in your source file.

Just above the function, copy/paste this from Experiments:

Code: Select all

double GetStupidStep(string symbol, int tf, double sensi, double size, int sshift, int ap, int buffer, int shift)
{

   /*
   Passed parameters:
      - symbol = chart symbol
      - tf = time frame
      - sensi = StepSensitivity
      - size = StepSize
      - sshift = StepShift
      - ap = StepPrice
      - buffer = the indi buffer being interrogated
      - shift = the candle shift to the left relative to now. shift = 0 means now. 
                shift = 4 means 4 candles ago etc
   */
   
   return(iCustom(symbol, tf, "StepMA new 1.05", sensi, size, sshift, ap,
          false, false, false, false, false, false, buffer, shift));
   
  
   
}//End double GetStupidStep(string symbol, int tf, double sensi, double size, int sshft, int ap, int buffer, int shift)
Now copy/paste this over the top of the existing void ReadIndicatorValues():

Code: Select all

void ReadIndicatorValues()
{

    int cc = 0;
   
   //Declare a shift for use with indicators.
   int shift = 0;
   if (!EveryTickMode)
   {
      shift = 1;
   }//if (!EveryTickMode)
   
   //Declare a datetime variable to force cca reading only at the open of a new candle.
   static datetime OldCcaReadTime = 0;
   //Accommodate every tick mode
   if (EveryTickMode)
      OldCcaReadTime = 0;
   
   //Allow easy experimentation.
   //shift = 2;
      
   //Read the indi
   if (OldCcaReadTime != iTime(Symbol(), TradingTimeFrame, 0) )
   {
      OldCcaReadTime = iTime(Symbol(), TradingTimeFrame, 0);
      
      //Is the line green at shift?
      StepMaColour[1] = green;
      //Or is it red? The indi returns EMPTY_VALUE when the line is green.
      double val = GetStupidStep(Symbol(), TradingTimeFrame, StepSensitivity, StepSize,
                                 StepShift, StepPrice, 1, shift);
      //It returns a price if brown
      if (!CloseEnough(val, EMPTY_VALUE) )
         StepMaColour[1] = red;

      //Is the line green at shift  1?
      StepMaColour[2] = green;
      //Or is it red? The indi returns EMPTY_VALUE when the line is green.
      val = GetStupidStep(Symbol(), TradingTimeFrame, StepSensitivity, StepSize,
                                 StepShift, StepPrice, 1, shift + 1);
      //It returns a price if brown
      if (!CloseEnough(val, EMPTY_VALUE) )
         StepMaColour[2] = red;

      //What is the colour change status of the line?
      //Is it all green?
      if (StepMaColour[2] == green && StepMaColour[1] == green)
         StepMaChangeStatus = allgreen;
      
      //Is it all red?
      if (StepMaColour[2] == red && StepMaColour[1] == red)
         StepMaChangeStatus = allred;
      
      //Has it changed red to green?
      if (StepMaColour[2] == red && StepMaColour[1] == green)
         StepMaChangeStatus = justturnedgreen;
      
      //Has it changed green to red?
      if (StepMaColour[2] == green && StepMaColour[1] == red)
         StepMaChangeStatus = justturnedred;

   }//if (OldCcaReadTime != iTime(Symbol(), TradingTimeFrame, 0) )
   
   /////////////////////////////////////////////////////////////////////////////////////
   //IN HERE GOES CODE TO CALL OTHER CCA'S. I SHALL ADD THIS LATER
   
   /////////////////////////////////////////////////////////////////////////////////////
   
   
   
   /////////////////////////////////////////////////////////////////////////////////////
   
   
   
}//End void ReadIndicatorValues()
I am referring to line numbers in the code snippet just above.

Lines 7 - 11. I am often comparing two values. Sometimes it is the value now with the Close(1). Other times it is the Close(1) with Close(2). Declaring shift and setting its value according to EveryTickMode means I merely have to use shift and shift + 1 when passing this parameter to the indi reading function.

Lines 14 - 16: I do not want an EA that works only at the open of a new candle reading an indi at every tick. This variable declaration accommodates both possible values for EveryTickMode.

Line 20 is commented out. I use it whilst adding the code to check that I am coding the calculations correctly. For example, I see that the CCA line was red 10 candles ago and green 9 candles ago. I set shift to 9 and can check that the chart feedback is correct.

Lines 23 to 43 reads the indi and calculates the line colours, saving this data in StepMaColour[1] and StepMaColour[2].

Lines 45 - 60 save the colour change status of the line in StepMaChangeStatus. There are 4 possible states and the comment at the head of each snippet describes the state being investigated. At the end of this process, StepMaChangeStatus will be one of the 4 colour change status constants and its state will show up on the chart.

:xm:

Next up: putting all this together to spot a trade trigger.
Author:  SteveHopwood [ Sun Nov 29, 2015 2:18 pm ]
Post subject:  Putting all this together to spot a trade trigger
Here is the code in ReadIndicatorValues() that detects a trade trigger.

Code: Select all

/////////////////////////////////////////////////////////////////////////////////////
   //Now to calculate whether we have a trade signal or not. I do this
   //by combining all the indi's used by the trading system.
   //Turn off any previous signal
   BuySignal = false;
   SellSignal = false;
   
   //Look for a Buy signal
   if (TtfStepMaChangeStatus == justturnedgreen)
      BuySignal = true;
      
   //Look for a sell signal
   if (!BuySignal)
      if (TtfStepMaChangeStatus == justturnedred)
         SellSignal = true;   

   //Close trades on an opposite direction signal
   BuyCloseSignal = false;
   SellCloseSignal = false;
   
   if (BuySignal)
      SellCloseSignal = true;
   
   if (SellSignal)
      BuyCloseSignal = true;

   /////////////////////////////////////////////////////////////////////////////////////
It goes underneath this line:
}//if (OldCcaReadTime != iTime(Symbol(), TradingTimeFrame, 0) )

I like to put all the indicators in use together in ReadIndicatorValues and set Buy/SellSignal to true if they all match requirements. This simplifies the code in LookForTradingOpportunities().

I start by setting Buy/SellSignal to false, then reset the relevant one if there has been a colour change.

BuyCloseSignal and SellCloseSignal I declare just underneath BuySignal and SellSignal in 'General inputs'.

Their function is to tell LookForTradeClosure() that there has been a trading time frame trade signal and to close any opposite direction trade. You will see why this is necessary when I introduce a higher time frame CCA filter.

Next up: Editing LookForTradingOpportunities()

:xm:
Author:  SteveHopwood [ Sun Nov 29, 2015 3:09 pm ]
Post subject:  Editing LookForTradingOpportunities()
Most of the work is already done if you are using the latest shell versions. Go to the LookForTradingOpportunities() function.

Find the two comments:
//Specific system filters and bookmark them.

What follows in older versions of the shells is the commented out line:
//if (some condition) SendLong=true;
This needs replacing by:

Code: Select all

   //Specific system filters
   if (BuySignal) 
      SendLong = true;
Then go to the second bookmark and replace the older:
//if (some condition) SendShort=true;
and replace it with:

Code: Select all

      //Specific system filters
      if (SellSignal) 
         SendShort = true;
One final step that always needs doing. Find the comment
//DELETE THIS
a little further down and delete this snippet:

Code: Select all

////////////////////////////////////////////////////////////////////////////////////////
//DELETE THIS
   SendLong=false; SendShort=false;
////////////////////////////////////////////////////////////////////////////////////////
I have this trade-cancelling mechanism to stop trades being sent willy-nilly as I am developing the code.

Next up: more to add to ReadIndicatorValues()


:xm:
All times are UTC Page 1 of 3

Powered by phpBB® Forum Software © phpBB Limited