My "favorite" topic again. I hate these kind of strategies with passion 
You can search for "Sure-Fire" in the forum. I posted the same example that I did looong time ago many times. But my opinion is that hedging is just a stupid way to do Martingale. It makes the whole process hard to make, hard to maintain and more complex in general. Jim Dandy is on the same opinion: https://www.youtube.com/watch?v=6ux63AhGmFE
@Jim67, almost nothing will change if you delete your ~100 projects.
The problem I'm investigating now happens (I believe) when somebody with 1000s of projects is creating a new project. Although the exact way the problem happens doesn't really matter. Normal accounts are like yours - not 1000s of projects, not 1000s of blocks in their projects. But there are these students of the guy that I mentioned before that have the 1000s of projects and some of them have projects with 1000s of blocks. When they are active during the day, they are "benchmarking" the website. Because of the way these guys are using the website, those slow database queries are showing up.
But the slow database queries are slow, because they are not properly optimized. In databases there is something called "index", which is when part of the database is cached in the RAM and is used for quick searches. Well, what I'm discovering these days is that some of the queries I wrote are not using the indexes effectively. If everything is well optimized, those 1000s of blocks should be no problem at all and the queries should happen in just a few milliseconds. Because they are not optimized now, they happen in few seconds.
But again, these are just a few queries that just a few accounts are "abusing". Why everyone experiences slow moments is that while the database is processing these slow queries, the other queries are waiting.
I added these options in Condition - Market properties - Symbol Trade Time. I have no idea whether it works or not
.ex4 files contain binary data, generated by the compiler (metaeditor). But more importantly, these files are supposed to be encrypted and not leak information about the source code of the program.
In the picture you can see blue text "stopped". Which is automatically generated after the end of the EA's work. But if you use "Change Status to" this text can be changed to whatever text you want.
The idea is that you can choose some blocks to tell you something in the chart. The alternative is of course to use "Draw Text"
Today I investigated this error a little bit more. One user sent me his history data and I was able to get the error myself. At the end, I don't know how to fix the problem, but this is what I understood.
Each candle has OHLC, Volume and also Time. "Once per bar" works by reading the Time from the candle, remembering that time and then when the time changes (when a new candle is added), it can pass again and remember the new time. Do this over and over and the block passes once per bar.
To get the time I used a function called CopyTime. This function would read the data from just one candle, and then it would put the result in a dynamic array, which initially has size of 0. When the data is put into the array, its size would automatically change to 1. Then, that single value from the array would be read, which usually happens without problems. But when the function fails, the array doesn't change, its size remains 0 and that's why later it shows "array out of range".
While the error says "array out of range", the problem comes from the inability to read that candle. And in the tests I did today, CopyTime wasn't able to read any candle.
First I did a fix, so that when CopyTime fails, it won't even try to read the value from the array, it would just do nothing and "Once per bar" won't pass. Muted error, the EA just tried to do what it can.
Then I tested iTime, which seems to be able to get the time from the previous candle somehow. However, then I realized that if lower timeframe is selected in "Once per bar", then iTime (and also CopyTime) could fail.
So the whole situation happens because something in the history data is not right. But I don't really know how to fix the problem with these functions. I can mute the error so it won't appear, or print another more descriptive error.
Be careful with the first 2 options in "Draw..." blocks. Look here - https://fxdreema.com/help/working-with/chart-objects And also yesterday I added description for those 2 options, just click on their titles when they become yellow.
I think it works fine in general. During the day there are more active people (especially lately with the Persian guys) and maybe things are getting slower, sometimes even inresponsive for few seconds. But it should work relatively fine, especially for small projects.
If someone is working on a small project and the website appears too slow at any time of the day, my guess is that this is a network problem.
@OntradingX, I can see that at the moment you are working on a project with almost 500 blocks. It's quick to open the blocks. I can export .mq5 file in ~ 1 second, and .ex5 file in ~5 seconds. What are your times when you do the same?
Well, I have this row of code somewhere in the functions:
size=((value/100)*AccountBalance())/(sl*((TickValue/ticksize)*point)*PipValue(symbol))
but what is what... hard to explain everything right now. Plus, the lot size would be rounded to the nearest possible, don't expect lot size such as 0.0434
Note that the blocks have numbers. Most of the time these numbers doesn't matter, but sometimes they do.
Take a look at this: https://fxdreema.com/documentation/builder/builder-basic-rules#block-numbers
If you have 10 blocks connected one after another, their numbers doesn't matter, because the order of execution is from the first block to the last, and there is only one possible path.
However, things are a little bit different when there are 2 or more possible paths. If you have a block that is connected to 2 or more blocks after it, which of these block should run first? They can't run at the same time, because the code is synchronous.
This is what you have in your last example:
Here block 4 doesn't even matter, it just passes. But what follows block 4? Blocks 7, 3, 1 and 5. Ok... let me rearrange the blocks just a little bit:
Now there is a visual difference, obviously, I changed the position of the blocks. Will this example produce different results in the Tester? If the position of the blocks mattered, yes. But the position of the blocks doesn't matter, so the results will be absolutely the same, and in your opinion - wrong. What matters is the number of blocks. The lower number runs first. This means that the order of execution of blocks is 1, then 3, then 5, then 7.
Let's imagine that you already have one position. Let's look at what happens on the very first run of these blocks.
Change the number of block 3 to say 30 and the bug will be fixed.
You know, I always reject proposals. I just can't work with people and for their projects. I'm doing my little thing the way I feel and this is what I can
At this point I'm convinced that even MetaQuoted don't know what they are doing with their Positions/Orders/Deals functions.
This bug happens in a code that I rewrote months ago. I was very careful to write everything properly, and I believe I did. I also made some tests to ensure that everything is good, and it was.
Since then, I didn't touch any MQL5 code, so this bug (and possibly other bugs) is introduced after some of the newest MT5 builds.
I wanted to explain what the problem is and why I think it makes no sense, but I think it's too complicated and maybe no one even cares.
But in short, now it seems that when we want to use for example this function:
long HistoryDealGetDouble(
ulong ticket_number, // Ticket
ENUM_DEAL_PROPERTY_DOUBLE property_id // Property identifier
);
... first we have to use this one to select the deal:
bool HistoryDealSelect(
ulong ticket // Deal ticket
);
... which is crazy, because why do we have this ticket_number property in HistoryDealGetDouble(), if not to select the deal and get whatever data we need?
It's probably the same mess with HistoryOrderGet... functions.
One way for me to fix this is to scan the code I wrote for any usages of HistoryDealGet... and HistoryOrderGet... functions, and put some HistoryDealSelect() and HistoryOrderSelect() functions on top. Then hope to remember in the future that I have to do every time, because it's not intuitive at all.
And the other way is to write overloads for all HistoryDealGet... and HistoryOrderGet... functions without the ticket_number property. But then if MetaQuotes decide to to the same, there will be errors.
This was possible years ago with some decompilers, when MetaTrader was at version 224. But now I have no idea who can do that.
I did some fixes in many files, I hope it is ok now. If there were similar bugs in other blocks, maybe I fixed them as well.
And instead of using block 15, the formula can be written directly into the input filed where you normally see the lot size.
It is too big project for the compiler at this point
Set the Trailing step to 5. Here is more info: https://fxdreema.com/help/working-with/trailing-stop
Now, the first step where you want to put SL to BE+1pip, this can be done with the Break even block. But then in the Trailing stop block you should set some "Trailing Start" to make it wait until there is some profit, and then to start moving SL.
Actually depends on what the initial SL needs to be. If it needs to be at 5 pips (at most), then I think you can forget about that +1pip and just use the Trailing stop only (with 5 pips step)
How often do you have problems with the website? People from China told me that their connection with the website is bad, but I have no idea how much. I personally live far away from the actual server and I have delay for each request about 120 ms, but even with that the website works fast enough for my taste (and I like speed). But maybe there is something else, I don't know...
There are few possible problems with .ex4/.ex5 files. The first problem is that the compiler (metaeditor.exe) starts very slow. This program can run as a normal Windows program as you know (MetaEditor) and also in command line mode. But with every new version the program starts slower and slower in command line mode. Unfortunately I can't fix that. But half of the waiting time is because of that.
The other half of the time you wait is for the file to be downloaded, because it is bigger that 1MB. Here I have some feeling that the speed should be faster, so I will investigate this.
There is another possible reason - the compile time could be slow. This is the time for which the MQL code is compiled. For your project this time is not very small, probably because of the size of the source code. But fortunately it compiles relatively fast. Because I noticed few times that with certain content in the MQL code, the compilation time becomes huge.