You are missing trading opportunities:
- Free trading apps
- Over 8,000 signals for copying
- Economic news for exploring financial markets
Registration
Log in
You agree to website policy and terms of use
If you do not have an account, please register
You think I don't check. The lot size is checked in a separate function
Limits are not needed here, because Stop Loss and Take Profit are equal to zero at trade opening.RefreshRates() updates data at lot calculation. Of course, there is no check of connection, etc. before each entry, but that's not the point. If OrderSend sent a request, there would be a specific error: 130, 131, etc. But what I have is.
Not trying to send an order to open at all. Even in the last test, when I set a check position in the OnInit() function.
It is possible. But I have already double-checked everything. I do not know where to go next.
In the lot normalisation function, you round up the lot after checking it to the max/min value.
Well, yes, I do.
MathRound();
P.S. I think you have to dig from input parameters, because it happens that it passes. Do a "foolproof" check on each parameter.I'm not even talking about the validator test logs. But at least the parameters that are NOT validated might be possible to send. There's nothing to catch on at all to fix the code. I understand that the variability of choosing testing parameters may be infinite. You may set a variable of int type either to +50000 or -45000. But I can't simply limit some input parameters to some range of values because it will be different for different instruments.
You need to make sure that the trading lot is valid in all cases. It is not for nothing that I pointed out that you change the lot in your code after it has been checked for a valid size range.
And it is the check for absolutely stupid input parameters that must be done.
There is no problem with the lot. It is checked for max/min. Before rounding it is divided by step, then the rounded integer is multiplied by step again. We obtain a perfectly correct lot.
_lot(0.568)/step(0.01)=56.8
MathRound(56.8)=57
57*step(0.01)=0.57
Next, it is checked to see if there is enough free margin to open. The validator doesn't swear at lot at all. It does not see trading functions, apparently, because of incorrect input parameters. The Expert Advisor simply does not make trades at all with a certain combination of them! It's not like I have a non-conditioned martin, and I don't have a net maker that opens on every candlestick. How do I explain to the validator that the EA logically does not make trades with certain parameters?
There is no problem with the lot. It is checked for max/min. Before rounding it is divided by step, then the rounded integer is multiplied by step again. We obtain a perfectly correct lot.
_lot(0.568)/step(0.01)=56.8
MathRound(56.8)=57
57*step(0.01)=0.57
Next, it is checked to see if there is enough free margin to open. The validator doesn't swear at lot at all. It does not see trading functions, apparently, because of incorrect input parameters. The Expert Advisor simply does not make trades at all with a certain combination of them! It's not like I have a non-conditioned martin, and I don't have a net maker that opens on every candlestick. How can I explain to the validator that the EA logically does not make trades using certain parameters?
Do not explain, but make the EA correct the wrong input parameters. Preferably with a message to the journal about their invalid value and the correction to the valid value.
And, if for some reason you want to make the user responsible for entering incorrect parameters in the real world, the user should be notified of the incorrect parameters.
But for the tester, they also need to be corrected - so that the EA trades.
So how can they be adjusted if there are some parameters for EURUSD and others for Gold, for example. Right now the default settings are more or less tolerable for the major pairs, but for gold they will not work at all. There will be no trades there. That's why the parameters exist (as I understand it), to adapt them to each instrument. If everything were that easy, I would have embedded all parameters into the Expert Advisor and would not have sent anything to the outer ones.
Another bug of the validator is that it does not see other timeframes at all. I have bypassed it, but to the detriment of the algorithm to some extent. The Expert Advisor takes data from other timeframes, from weekly, D1, H4, etc. to M1. But the data comes null, as I found out through numerous experiments. There is nothing we can do about it, we can only work around it. Why do we have to modify the Expert Advisor to the detriment of the algorithm? Isn't it the other way around? The validator should be adapted to the tests. Otherwise, checking a perfectly working EA turns into a kind of hard labor!
So how can they be adjusted if there are some parameters for EURUSD and others for Gold, for example. Right now the default settings are more or less tolerable for the major pairs, but for Gold they will not work at all. There will be no trades there. That's why the parameters exist (as I understand it), to adapt them to each instrument. If everything were that simple, I would have embedded all parameters into the Expert Advisor and would not have sent anything to the outer ones.
You already put division by 0 just before OrderSend - and there was such error. So it gets to OrderSend, but does not open. So lots/margin/limits/price, some of them are unaccounted for.
Maxim, if any of these things are not accounted for, the validator will give a very definite error: 130, 131, 134, 145 etc. That's not the case here!
P.S. Believe me, I've sent over a hundred validations in 4 days, and tried a lot of options.
Yes, it reaches division by 0 (hence OrderSend) immediately. And it generates an error.
But if I send for check the Expert Advisor without division by 0 in the code, it somehow magically sets parameters which do not open trades at all during the specified period and returns an error. This is my version of what is happening, but apparently it is not far from the truth.