My shell EA code

[K-Lander]

Hi Steve,
Attached I am sending Bare Bones with a working ForceSleepUntilNextBar feature.

A friendly reminder to anyone using the shells: Remember to DELETE the failsafe on the code (you´ll find it within the LookForTradingOpportunities function). Nothing will ever trigger a trade unless you do it (I forgot about it and took me 2 hours to figure out why the bugger doesn´t fire).

Thanks for the help Steve, and for the coding lesson.

All the best, and stay safe in these strange times.

Ariel

The subconscious is an amazing thingy and mine was at work as I typed the above. It just told me that I had given you duff info about the call to the function as well. Think about this call:

Code: Select all

if (ForceSleepUntilNextBar && DidTradeCloseBeforeCurrentCandle()) return (true);
   else
   return (false);  

This will also return 'false' if you have ForceSleepUntilNextBar set to 'false' to disable this filter, so the bot will never Trade. My fault. Here is the corrected code:

Code: Select all

   if (ForceSleepUntilNextBar)
   {
      if (DidTradeCloseBeforeCurrentCandle() ) return (true);
      else
      return (false);
   }//if (ForceSleepUntilNextBar)

[simplex]

Hi all,
I'm just working my way through this formidable piece of software. Stumbled over the object handling functionality:

Code: Select all

if (ObjectFind(LineName) == -1) {
	ObjectCreate(LineName, OBJ_HLINE, 0, TimeCurrent(), 0);
	...
}

https://docs.mql4.com/objects/objectfind states:

If the object is not found, the function returns a negative number.

So that return value is not -1 necessarily.
Maybe it's worth considering to replace

Code: Select all

ObjectFind(LineName) == -1

by

Code: Select all

ObjectFind(LineName) < 0

just to be sure ... as sure as one can be using mql ...
There are several similar ObjectFind calls in the source code.

[SteveHopwood]

Hi all,
I'm just working my way through this formidable piece of software. Stumbled over the object handling functionality:

Code: Select all

if (ObjectFind(LineName) == -1) {
	ObjectCreate(LineName, OBJ_HLINE, 0, TimeCurrent(), 0);
	...
}

https://docs.mql4.com/objects/objectfind states:

If the object is not found, the function returns a negative number.

So that return value is not -1 necessarily.
Maybe it's worth considering to replace

Code: Select all

ObjectFind(LineName) == -1

by

Code: Select all

ObjectFind(LineName) < 0

just to be sure ... as sure as one can be using mql ...
There are several similar ObjectFind calls in the source code.

Thanks for this. Brilliant point.

I am not going to do anything with this immediately as I can make the changes as I use the code. Plus, anyone such as yourself, can read your post and make the changes themselves. Anyone who cannot, cannot use the shells.

Thanks again. Hugely appreciated.

[simplex]

Plus, anyone such as yourself, can read your post and make the changes themselves. Anyone who cannot, cannot use the shells.

Agree & thanks! Now for my next find, which dives a little bit deeper in the trading logic. See function LookForTradingOpportunities():

Code: Select all

	if (BuySignal) {
		SendLong = true;
	}
	if (SendLong) {       // User choice of trade direction
		if (!TradeLong) {
			return;
		}

This is how buy trades are started. For sell trades, it looks like this:

Code: Select all

	if (!SendLong) {
		if (SellSignal) {
			SendShort = true;
		}
		if (SendShort) {
			if (!TradeShort) {      // User choice of trade direction
				return;
			}

So sell signals are only being processed if there's no buy signal present. In my opinion, long and short trades are generally equitable. By this logic, long trades are prioritized over short trades.

This may work in a perfect world. But let's assume we as coders implement some sort of faulty logic when it comes to analyse the market for entry opportunities. Allright: this is highly unlikely, but let's just assume the impossible is happening: our trading logic issues a buy and a sell signal at the same time for a given pair.

In above logic, the long trade will be placed, while the short trade is silently ignored. Do I want that? Don't know about you, but I do not. What I find alarming most of all is the fact that ignoring the short trades obviously happens silently. Maybe there are security checks later on dealing with such a situation, which I possibly am not aware of yet. Anyway, I believe it's better to deal with this case before actually placing trades.

So this is my proposal to (hopefully) improve that bit of the shell code:

Code: Select all

	// Security check: is our trading system going haywire? (simplex mod)
	if (BuySignal && SellSignal) {
		/* 
			do whatever seems appropriate to ring the alarm bells ...
			... suspend trading?
			... close / delete all trades?
			... display visible and / or audible alarm?
			... send an email to Steve for immediate help? ;-)
			... 
		 */
		return;
	}
	
	if (BuySignal) {
		SendLong = true;
	}
	if (SendLong) {
...
	if (SellSignal) {
		SendShort = true;
	}
	if (SendShort) {
...

Now long and short trades are treated in the exact same manner, and on the same indentation level in our code. Furthermore we have the opportunity to implement some code to ring the alarm bells if the unthinkable is actually happening.

I'm just working on this mod, it's not yet ready, but I'd like to discuss my proposal here, before possibly running (coding) into a completely wrong direction. Maybe this idea is worth to find its way into the shell itself, not only in my upcoming EA's. In the end, it makes the shell a bit more foolproof (which suits me perfectly!), because it deals with a faulty signal logic in a more appropriate manner as compared to just ignoring it.

[simplex]

Still using the incredible Barebones 17-6-20.mq4 once in a while as a reference for certain tasks in MT5. So just today I stumbled over the following code, which I believe contains a bug. Please refer to function

Code: Select all

void TrailingStopLoss(int ticket)

line 3206:

Code: Select all

       if (OrderType()==OP_SELL)
       {
          if (sl > OrderOpenPrice() ) return;//Not at breakeven yet
          ...
          if (CloseEnough(sl, 0) ) sl = MathMin(OrderStopLoss(), OrderOpenPrice());
          if (CloseEnough(sl, 0) ) sl = OrderOpenPrice();
          if (Bid <= sl  - (TrailingStopPips / factor))//George
          {
             ...
          }

Since we're working on SELL orders here, shouldn't this be Ask instead of Bid?

Cheers, sx

[SteveHopwood]

Still using the incredible Barebones 17-6-20.mq4 once in a while as a reference for certain tasks in MT5. So just today I stumbled over the following code, which I believe contains a bug. Please refer to function

Code: Select all

void TrailingStopLoss(int ticket)

line 3206:

Code: Select all

       if (OrderType()==OP_SELL)
       {
          if (sl > OrderOpenPrice() ) return;//Not at breakeven yet
          ...
          if (CloseEnough(sl, 0) ) sl = MathMin(OrderStopLoss(), OrderOpenPrice());
          if (CloseEnough(sl, 0) ) sl = OrderOpenPrice();
          if (Bid <= sl  - (TrailingStopPips / factor))//George
          {
             ...
          }

Since we're working on SELL orders here, shouldn't this be Ask instead of Bid?

Cheers, sx

I have been coding this stuff for about 16 years now and still am not sure about the answer to your question - one I have asked myself umpteen times over the years.

Notice the comment following this line of code:
if (Bid <= sl - (TrailingStopPips / factor))//George

George was SHF member gaheitman. At the time, he knew more about coding than most of us here. He was most helpful and I adopted anything he suggested. Sadly, he has not visited here for more than 5 years, so I guess that age took its usual toll. It is coming to us all but I still think about him every time I use one of the shells.

These days, I code closing buys at the Bid and sells at the Ask with one difference. I use the minimal spreads of Afterprime to minimise any damage that my possible misconceptions might cause. Sorry not to be more definitive in my answer.

Of course, none of this really matters unless: an EA responds to lines drawn on a chart to crossing said tpsl lines to close a trade - those are a real headache; your broker is a criminal and the spreads are monumental - bugger all I can do about that.

I hope this helps whilst not being sure it will.

[markft]

If I understand correctly from the code section, this is where we are managing the trailing stop for a Sell order. Yes I think you are right and that should be the Ask, as we would be executing a market order to buy, to close the sell, at the Ask price. That being said, as Stave mentioned, this is usually not significant almost all of the time, unless somehow the spreads have widened a lot.

[SteveHopwood]

The latest updates to the shells are in post 1 - "Updated versions 19th Dec 2024.zip".

nwesterhuijs wrote to me nearly 3 years ago pointing out a missing doubles conversion of its extern int. This line needed adding to OnInit():
DistanceBetweenTrades = DistanceBetweenTradesPips;

This only applies to the versions that include grid trading.

Thanks Norbert. Sorry it has taken me so long to get around to this.

-----

A very minor issue. Those of you using the shells are familiar with the, "Expression not boolean" warning when compiling. I had coded return(0) instead of return(true) and so have corrected this.

-----

The next update is a big one for grid trading. I recently coded an ea for one of our members that works on grid stop orders. Taking a buy stops as an example, the first stop in the grid would fill then the market would fall and leave a large gap in between the market and the open market order. The ea would send a new stop order to fill the gap.

Never mind the details, but in a complicated position there could be bunches of stop and market orders close together - not something we wanted. Nothing I coded would stop this happening.

I have been playing with grids of stop orders on XAUUSD and wanted a simple expert with buttons on the chart, to send and delete grids at the click of the relevant button. I used a lot of the code from one of my grid-sending scripts and noticed that the stops never bunched if I added more stops.

I looked into the DoesTradeExist() function and saw that shf member odrisb had solved the problem for me. Goodness knows when but a long time ago and I had forgotten. I added this to the ea I described earlier and the bunching problem was instantly solved.

This was an invaluable contribution odrisb, so many thanks.

This only applies to the grid trading versions.

------

Those of you who use the LotsPerDollopOfCash feature are familiar with it not working properly. For example, using 0.01 lots per $1,000 would see the lot size increasing to 0.02 when your choice of the balance or equity reached $1,500 rather than waiting until it reached $2,000.

I finally sorted this out in developing the ea I described earlier, so I have updated all versions.

[SteveHopwood]

The latest zip file is in post 1 - "Shell codes updated 16th Jan 2025.zip"

They fix a tiny bug that I have been meaning to correct for ages, but forget about until it causes me to spend a frustrating couple of hours thinking that the is a bug elsewhere.

Guess why I suddenly remembered again.

You do not need to download if you can already use the shells. The bug was in this code block:

Code: Select all

            //Lowest trade price
            if (OrderOpenPrice() > LowestSellStopPrice)
            {
               LowestSellStopPrice = OrderOpenPrice();
               LowestSellStopTicketNo = OrderTicket();
            }//if (OrderOpenPrice() < LowestSellStopPrice)

LowestSellStopPrice is set to 1,000,000 at the top of CountOpenTrades(), so the first line of the block could never execute as intended. The conditional should be:
if (OrderOpenPrice() < LowestSellStopPrice)

You do not need the download as you are already using the shells. The DIY is to do a search for:
if (OrderOpenPrice() > LowestSellStopPrice)

Then change '>' to '<'.