Question for the pros

[Bruce Flea]

Okay... I have been working my way into learning to program, much to the credit of Coder's Guru, and the esteemed Mr. Hopwood. Much thanks to both:)

I can manipulate existing code to some extent, and get it to do what I want eventually. LOL

However, in the EA I am trying to code up, my stop loss is not a static setup that can be manipulated using external variables, such as 30 to the stop, and 60 to the TP points.

What would I now study, to find a way to use the last candle, or if it was within two or three candle points, the last swing high or low, and then have my stop move to B/E once it's up 20 pips or so?

I've been reading up on OrderSend, OrderModify, and learning the functions of those and the other options, but can't wrap my noggin around making my stops dynamic. The logic gets fuzzy

I've searched high and low for some kind of examples, but those types of stops, and t/p ideas aren't very common. I don't expect anyone to code anything, I would just like some starters on how one would go about it, and what to study to catch on to it mentally.


Any suggestions?

[SteveHopwood]

Wonderful to see you trying to help yourself. What you are doing now is how I started.

To use the previous candle as your stops, and keeping things simple, use High[1] and Low[1]. These functions return the price of the hilo of the candle referenced by the digit in the square brackets for the current chart time frame.

So, High[1] is the high of the previous candle. High[2] would give you the high of two candles ago etc.

Suppose you want your stop for a buy trade to be the low of the previous candle:
double stop = Low[1];

For detecting a swing, we have the invaluable Fractals indi that comes with Empty4.
Find the swinghigh/low with these code blocks:

Code: Select all

double GetLow()
{

   double v;
   
   for (int cc = 1; cc <= Bars; cc++)
   {
      v = iFractals(NULL, 0, MODE_LOWER, cc);
      if (v != 0) return(v);
   }//for (int cc = 1; cc <= Bars; cc++)
   

}//double GetLow()

double GetHigh()
{

   double v;
   
   for (int cc = 1; cc <= Bars; cc++)
   {
      v = iFractals(NULL, 0, MODE_UPPER, cc);
      if (v != 0) return(v);
   }//for (int cc = 1; cc <= Bars; cc++)
   

}//double GetHigh()

Then call them with previously delared variable such as:
double SwingHigh;//Declared in the general section
SwingHigh = GetHigh();//Called within a function that requires the value of the latest swing high

Have fun. Experiment, Learn. Use Google. Ask questions. This is how I learned to code mql4. Don't always expect detailed answers from me. I will not always be in the mood to provide them.

[Bruce Flea]

Thank you very much for that.

I can get it when I see it right now, but I'm not yet familiar enough with things to just go from scratch.
Your samples made it much easier. I can muck around a bit with it I think, and cobble together what I need.

And I do all that you suggested. It's amazing what comes up when you paste a snippet of code in Google looking for an explanation

[dietcoke]

Bruce, the function below will return a stop value CandleStopLookback bars from the orderopentime of the selected order.

You can also specify the timeframe for the lookback and a minimum stop in pips.

I've lifted this from a more complex function I'm using, so it's user beware but you can get the idea of how you can do lookbacks with this.

Code: Select all

//use extreme of the lookback candle to set initial stop
extern bool		UseCandleStop			=true;
//Number of candles to lookback
extern int		CandleStopLookback	=1;
//candlestop TF
extern int		CandleStopTF			= PERIOD_H1;
//Minstop in pips
extern int           MinStop  = 20;


double ApplyCandleStop()
{
	
	//THIS FUNCTION EXPECTS TO BE CALLED 
	//WITH A TICKET ALREADY SELECTED

	//first find the open time of the order
	//then find the candle for that time and lookback x candles
	//then set the stop below/above this candle
	
	
   bool result=false;
   int err, stoplevel, failcount = 0,	ordercandleshift=0;
	double stop=0;
	
        //Convert minstop to points
	double minstop  = MinStop * Point;

	//get the order open time
	datetime ordertime = OrderOpenTime( ) ;

	// using the order open time, get the start shift of the candle
	ordercandleshift = iBarShift(Symbol(), CandleStopTF, ordertime);

	//Get the spread to add to stop for closing sell orders
	double spread = MarketInfo(Symbol(), MODE_SPREAD) * Point;

	if (OrderType()== OP_BUY )
	{
		stop = iLow(NULL,CandleStopTF,CandleStopLookback + ordercandleshift);
		if(OrderOpenPrice() - minstop  < stop)
		{
			stop = OrderOpenPrice() - minstop  ;
		}
	}

	if (OrderType()== OP_SELL )
	{
		stop =  iHigh(NULL,CandleStopTF,CandleStopLookback + ordercandleshift) +  spread;
		if(OrderOpenPrice() +  minstop  + spread > stop)
		{
			stop = OrderOpenPrice() + minstop  ;// + spread; dunno about this
		}
	}

	return(stop);
}

[Bruce Flea]

Thanks again to both of you!

I now have a fully functioning candle stop that I've also added the choice to use a moving average high or low, to trail without being quite so restrictive.

Now, another problem has come up for me.

I use price action for my signals. How a candle acts, and what it does compared to previous candles sets up my entry.

Currently, it takes five conditions to trigger a signal, and the indicator I came up with was working beautifully. I recently found another common element that would eliminate a bunch more signal candles that are most often unneeded, and has my EA take false signals.

But when I add that last condition, my visual indicator stops working correctly.

Is there a limit to how many conditions one can put in an expression?
I use a lot of greater thans, and less thans to derive my results.
I currently have it running in an order such as this(as it mostly compares highs, and lows of a succession of candles): if((a>a1)&&(c<b)&&(b1<c1)&&(h>=h1)&&(b<=a1))

I've tried taking the common elements between up and down signals out, and putting them in an "if" statement. And then isolating the uncommon ones in another nested "if", but that returns the same skewed results.

Is there an inherent limit to conditional statements within an expression I'm not aware of in mql4?

I've searched high and low for someone that ran into the same issue. I don't get "too complex an expression" errors. In fact, it compiles just fine. It just returns useless jibberish after that last condition.

I can take any ONE condition back out, and it works just fine. Five seems to be the limit. Can't figure it out.

Any ideas?

[SteveHopwood]

I do not know about the max nested thingy.

Usefully, it emerged in these forums that mql4 will check every if() conditional even though one of the earlier ones has failed - burning up processor power and wasting time.

So this expression will be evaluated right through to the end, even if a < a1:
if((a>a1)&&(c<b)&&(b1<c1)&&(h>=h1)&&(b<=a1))

So, better to go through the faff of evaluating each conditional one after the other i.e.

Code: Select all

if (a>a1)
{
    if (b1<c1)
    {
          if (h>=h1)
          {
                  Do something
           }//if (h>=h1)
    }//if (b1<c1)
}//if (a>a1)

If any of the above conditions fail, then mql4 will abandon the nested conditions.

As a general rule, if we are not professionally-trained programmers then we are better off avoiding complex expressions, however clever they make us feel. I only use them when I am absolutely certain of my ground - I have learned the folly of using them incorrectly through hours of bug-hunting.

KISS really helps when coding. Apart from anything else, you might have to work out what the code does in 6 months time...........................

[Bruce Flea]

Thanks Steve.
I've isolated my problem it rests in adding a third candle comparison to the expression.

The common elements I'm looking for involve something like this:

if((Close>Open)&&(Close1<Open1)&&(Close2<Open2))

Everything works fine until I add that 3rd candle back in the array. It doesn't even work if I skip comparing to the second candle back.

So I don't think my original assessment was correct. It definitely rests on the issues that arises when I ask for that last comparison.

Ever run into anything quite like that?

And is there a less challenging way to code it that shows me two up candles before a down, or two downs before an up before I add my final bit of conditions to identify a valid signal?

[SteveHopwood]

Thanks Steve.
I've isolated my problem it rests in adding a third candle comparison to the expression.

The common elements I'm looking for involve something like this:

if((Close>Open)&&(Close1<Open1)&&(Close2<Open2))

Everything works fine until I add that 3rd candle back in the array. It doesn't even work if I skip comparing to the second candle back.

So I don't think my original assessment was correct. It definitely rests on the issues that arises when I ask for that last comparison.

Ever run into anything quite like that?

And is there a less challenging way to code it that shows me two up candles before a down, or two downs before an up before I add my final bit of conditions to identify a valid signal?

A fiver says that you have done something really dim in the coding - this stops me dead for hours at a time.

Post the actual code here (pref with useful comments) and we can have a look.

[Bruce Flea]

A fiver says that you have done something really dim in the coding - this stops me dead for hours at a time.

Post the actual code here (pref with useful comments) and we can have a look.

LOL Actually I think it's fairly clean, and concise.

It's lightly commented, but very obvious as to what I'm doing. See what you think.

Everything rests on adding that third shift comparison. Works wonderful without it, and doesn't work at all with...

LOL Stupid 'puters!!

[SteveHopwood]

A fiver says that you have done something really dim in the coding - this stops me dead for hours at a time.

Post the actual code here (pref with useful comments) and we can have a look.

LOL Actually I think it's fairly clean, and concise.

It's lightly commented, but very obvious as to what I'm doing. See what you think.

Everything rests on adding that third shift comparison. Works wonderful without it, and doesn't work at all with...

LOL Stupid 'puters!!

No idea what the code does and not up to working it out either. You will have got one or more of you < and > the wrong way around.

It might take you hours to work out which one(s). When you finally do, you will want to slash your wrists.

Guess how I know?

Good luck. You need it.