Welcome to Forex-TSD!, one of the largest Forex forums worldwide, where you will be able to find the most complete and reliable Forex information imaginable.
From the list below, select the forum that you want to visit and register to post, as many times you want. It’s absolutely free. Click here for registering on Forex-TSD.
Exclusive Forum
The Exclusive Forum is the only paid section. Once you subscribe, you will get free access to real cutting-edge Trading Systems (automated and not), Indicators, Signals, Articles, etc., that will help and guide you, in ways that you could only imagine, with your Forex trading.
Elite Section
Get access to private discussions, specialized support, indicators and trading systems reported every week.
Advanced Elite Section
For professional traders, trading system developers and any other member who may need to use and/or convert, the most cutting-edge exclusive indicators and trading systems for MT4 and MT5.
I didn't check the lastest DerkWehler's version which seems a little complex, but the original version and the Omelette's ones have both the same bug.
The original version has also a recovery bug which was fixed by Omelette, but the code to fix it has itself the same bug.
Also, as Omelette said, it's NOT reliable to backtest EAs which are calling the OrderHistory, because during the backtest the history called is the real history of the account and NOT the pseudo history generated by the backtest itself. MQ is aware of this incredible bug, but don't care about it.
Now the bug itself comes from the fact that even if the History tab of the terminal is sorted by descending CloseTime, there is no guarantee that scanning the history from the last item the first order found is the last closed one. It is always needed to check this.
the initial code is
PHP Code:
int GetLotSizeFactor()
{
int histotal = OrdersHistoryTotal();
if (histotal > 0)
{
for(int cnt=histotal-1;cnt>=0;cnt--) // retrieve closed orders counting from the last.
{
if(OrderSelect(cnt,SELECT_BY_POS,MODE_HISTORY))
{
if(OrderSymbol()==Symbol() && OrderMagicNumber() == EA_MAGIC_NUM)
{
if(OrderProfit() < 0) // latest order close was a loss
{
LotSizeFactor = LotSizeFactor + 1;
return (LotSizeFactor);
}
else // latest order closed was a win
{
LotSizeFactor = LotSizeFactor - 1;
if (LotSizeFactor <= 0)
{
LotSizeFactor = 1;
}
return (LotSizeFactor);
}
}
}
}
}
return (LotSizeFactor); // no trades recorded in history just return the starting number.
}
I would sujest to replace this sub by this one:
PHP Code:
int GetLotSizeFactor()
{
int histotal = OrdersHistoryTotal();
datetime LastCloseTime;
bool LastIsLoss;
if (histotal == 0) return (LotSizeFactor); // no trades recorded in history just return the starting number.
else
{
for(int cnt=histotal-1;cnt>=0;cnt--) // retrieve the last closed order
{
if(OrderSelect(cnt,SELECT_BY_POS,MODE_HISTORY))
{
if(OrderSymbol()==Symbol() && OrderMagicNumber() == EA_MAGIC_NUM)
{
if(OrderCloseTime() > LastCloseTime)
{
LastCloseTime = OrderCloseTime();
LastIsLoss = OrderProfit() < 0;
}
}
}
}
if(LastCloseTime == 0) return (LotSizeFactor); // no trades recorded in history just return the starting number.
if(LastIsLoss) LotSizeFactor += 1;// latest order close was a loss
else LotSizeFactor -= 1;// latest order closed was a win
if (LotSizeFactor <= 0) LotSizeFactor = 1;
return (LotSizeFactor);
}
}
And it is still needed to correct the recovery code in the same manner.
The routine I would use is this one, it doesn't need to recover anything as the lot size is based on the last order directly, which I think is more reliable; it doesn't work with a size factor, but with a size unit :
Here's my monthly statement. I lost internet service around the end of the 1st week in September. The EA is still not placing the correct lot sizes so I will continue testing manually or until the EA is fixed. Good trading to all.
I've been running this strategy manually for several weeks due to the lot sizing problem, however, I've not yet tried Derk's version.
I trade 17 pairs, no PSAR or ADR, just the 200 EMA for the signal.
Using the mod below this has been extremely profitable.
If any pair is in a progression but have a new watermark account balance high I halt any and every progression and start over.
This has resulted in never having gone over a 3 unit lot size on any pair.
So what we want to tell the EA to do is, "If I have any pair that has been trading more than 1 unit and my balance reaches an all-time high, stop the propression and start over with 1 unit on every pair.'"
I've tried in vain to code this. If someone could make the mod this thing would be dynamite.
I've been running this strategy manually for several weeks due to the lot sizing problem, however, I've not yet tried Derk's version.
I trade 17 pairs, no PSAR or ADR, just the 200 EMA for the signal.
Using the mod below this has been extremely profitable.
If any pair is in a progression but have a new watermark account balance high I halt any and every progression and start over.
This has resulted in never having gone over a 3 unit lot size on any pair.
So what we want to tell the EA to do is, "If I have any pair that has been trading more than 1 unit and my balance reaches an all-time high, stop the propression and start over with 1 unit on every pair.'"
I've tried in vain to code this. If someone could make the mod this thing would be dynamite.
Thanks in advance.
may not be possible, since there is no way to keep track the balance.
anyway the idea is
check x time ago to see what is different, may be able to using array.
if the different is reach certain amount. then reset the unite.
Sure it's possible, "AccountBalance" is an MT language function.
It can be tracked with an array, I just don't know how to do it.
Something like "if the current account balance is higher than the maximum previous account balance that I've been tracking in this array then do this (fill in the blank..)".
If you only need to track highest balance, then you don't need an array for that, but simply a variable. Or two: one for the balance and one for its timestamp. If you want this to survive restart, you may need to keep it on file as well. (Alternatively include an initial account history scan to recover it; though this is easily done wrong )
The other condition, of a pair having traded 1 unit (since when the most recent
highest balance was reached [?]) requires account history processing; not too difficult either. (Or, it could possibly be maintained as a state flag that gets raised as soon as the condition arises; less computation but requires more care to ensure it is maintained correctly )
)
(Or, it could possibly be maintained as a state flag that gets raised as soon as the condition arises; less computation but requires more care to ensure it is maintained correctly )
Linear Mode
