Errors, bugs, questions - page 849
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
This is 2 terminals on 1 computer. To all suggestions from the terminal to update - I answer "yes".
The file was transferred to flash from another computer as .mql5, opened and compiled by different editors of two terminals.
Anyway, as I understood it, I need to upgrade MT...
If you are upgrading manually, you also need to transfer the /MQL5 folder, because it contains a huge number of standard libraries that you are using.
Since you have only transferred the executables and your source code as an mq5 file, you have made a mistake.
Upgraded to bild 695. An error started to pop up when compiling Object.mqh.
Upgraded to bild 695. An error started popping up when compiling Object.mqh.
Did you update automatically or did you just move the files?
If you did it automatically, when storing files in UserData, copy /MQL5 directory from program root to data directory (you can open it from File menu).
What happened to the economic calendar, does it exist?
Additional question: What data was it based on and how can it be "plugged in" to the DC?
This is the condition
if( mn < STP || mn >= STP )- it is worded this way for what reason? As it stands, it will work for any mn and STP. Why do we need to introduce it at all? And the next two options - there is a specific cutoff of certain situations.
But everything seems logical: one + two == tri (without going into details of calculations one, two and three) in all three variants.
That's what I'm talking about. I want to divide the common space (case 1) into two groups (cases 2 and 3). Logically, the expression one + two == tri should be true, but it's not. In the first condition one=148, and in the second one 172. Also not a match for two and for tri. I don't know what the problem is.
Maybe the problem lies in a common condition? Does this code depend on something else?
Just a trivial example:
condition (a): open if bar on H1 goes up. TP=SL=100
condition (b): Open if bar on H1 decreases. TP=SL=100
Additional condition: we do not check the conditions for the second time, if we already have a position.
Then if we enable (a) plus (b) we will open every time when TP/SL is triggered.
if we include (a) we will open in all first times plus (!!!!) a few more times when we didn't open because we opened before with condition (b)
and to include condition (b) only, similarly
Look more closely: this is exactly the comparison (one + two == tri) that is performed, for each of the options.
Well, this is a different question, namely, why the value of one from the first variant is not equal to the value of one from the second and third variants.
You introduce a restrictive condition in the second and third variants compared to the first variant. Consider why, for example, in the second variant the value of one increases compared to the first variant. It is not clear from the cited part of the code so far.
To the previous post.
In the third case: one=0, two=124, tri=124.
The data don't match, but they should, because the second and third cases are separate parts of the first condition. I cannot understand what the problem is.
PS: input int STP=200;
1. I choose both space2 (one) and space3 (two); 230 = 148 + 82, i.e. space2 (one) = 148 and space3 (two)=82.
2. ... Should remain 148, and became 172.
3. ... Should remain 82, and becomes 124.
That's what I'm talking about: the question for you iswhy the value of one from the first option doesn't equal the value of one from the second and third options.
To find an error in this logical assumption, I suggest to do very simply: print each case of increasing "spacesX" in all three variants, compare results and analyze for what reason "values of spaces2 and spaces3" are not the same.
Addendum. ilunga has already hinted that some transactions may be lost when moving from one variant to another. You have a killer function/method OpenPosition() embedded into the body of if() operator. And it works in different times depending on the condition checked by the if() operator.