Best posts made by fxDreema

I feel this has something to do with having the project opened in more than one tab. This usually leads to such unexpected and catastrophic consequences for the project. Not the fact that the same project is opened multiple times, but when you start doing something on an older instance of the project, there would be discrepancies with the newer version that is in the database on the server.

At the moment there is no functionality to auto-detect when the same project is opened 2 or more times at the same time, so personal attention is required.

Don't work on the same project in 2 or more different tabs. It will be possible to work on different projects this way, but not on a single one. If you have one project opened in one tab, close the other tabs where it is also opened. Also, if you have a tab opened at a certain project hours ago, reload the page just to be sure.

I got this message from my hosting:

=======================================================================================================

You are receiving this notification because your service WILL be affected by this maintenance.

DETAILS:
A power distribution unit in the rack is failing needs to be replaced. Your server will be down for the duration of the maintenance.

THE MAINTENANCE IS SCHEDULED AS FOLLOWS:
Start Time: Dec 19, 2016 - 8:00AM PST
End Time: Dec 19, 2016 - 11:00AM PST (3 hours)

We do not expect the work to take 3 hours, but we are scheduling the work for this long just in case we encounter unexpected issues. I apologize in advance for any inconvenience this may cause.

I'm also not sure about the performance implications of using many indicators in MQL5, I never tested so much indicators at once. But in programming, when we want to read something over and over again, and the reading itself tends to be slow, we cache it and read the cache instead. Also, there is one basic rule in programming called DRY (Don't Repeat Yourself) - the idea is to write some functionality once in some function, and run that function over and over again, instead of writing the same code at many places.

I see your project (the current one at the moment of writing this), which is a large project, and it's large because you have copied the same groups of blocks multiple times. This makes you a newbie in programming Well, to be fair, sometimes it's not very easy or intuitive to make things the good way in fxDreema. Sometimes it's not even possible.

But here are my suggestions.

• If you are using the same indicator with all the same settings in multiple blocks, make a "double" variable. Then, in "on Tick" before all other blocks set the value of that variable to be the indicator's value. For this use "Modify Variables" block with low block number, so it runs before the other blocks. And then in the blocks where the indicator is used, use the variable instead.
• Re-use the same group of blocks... if you know how. Unfortunately, this is tricky. If you know how a function works in any programming language, it's the same idea. You would have 1 block at the top of the group of blocks, which would be the block you run. The alternative for function arguments would be multiple variables. It's also possible to use arrays by the way.
• If possible, limit the execution of some groups of blocks. This depends, but let's say you have a group of blocks that runs on every tick without a problem, but it will be the same if it runs for example once per block, it will not change the behavior. In such case, put some "Once per bar" block. This will boost the performance.

No one I am the support team, but I can only write in english. Here in Bulgaria no one speaks in english, including me, so I would sound very very bad. And to be honest, I don't even want to talk to people live, I'm not very communicative

I think these problems are now happening because of the delays these days. I'm investigating the problem and I think it's because of users with giant projects. I noticed someone with almost 7k blocks, which is too big for this website. There are also users with 2k+ blocks, but most have smaller projects. I will have to put some limits on the creation of new blocks.

By the way, this problem with the missing titles is something new that I'm seeing. Usually the blocks remain visible, but they are totally broken. With this problem, only the titles are missing, but the blocks are good.

In any case, it's not a good idea to work on the same project from 2 places, 2 browsers, even 2 tabs in the same browser. But even if working from 1 place, now with these problems I think it's possible for the project to break.

If a project is broken, go back in the History one or more steps back.

EA 1 cannot control EA 2 directly, if this is what you want. Each EA is separate program and works independently from other EAs. If you want to send some information between EAs, you can do that with those Global Variables that appear when you click F3 (I call them Terminal Variables). This is pool of variables that can be read (and write) from all EAs in the same MetaTrader, but of course if EA 1 is not set up to read any of these variables, they just don't work for that EA.

I think I found the problem. There is a very slow database query that I wrote after I updated the forum. This query searches for existing user by email. This query is used every time when someone registers a new profile, or when someone is logging in with email.

The good news is that maybe huge projects are not so big of a problem

@miro1360 Or simply varName@pips

I fixed this slow query, now I expect everything to be smooth. The CPU already looks low and beautiful.

True. This was requested so many times since the beginning. Then I decided to implement it, but stucked in MQL4. I don't remember the exact reason why it was not possible, I only remember that it's just not possible because of MQL4

@Jim67, I'm not that surprized of the fact that sometimes projects are breaking, because this is not something new, it always happened. I must agree that the process of saving the project's current state it not very well polished. Basically, when you do some action (new block, blocks move, connection), everything in the browser (blocks, connections, areas) is read and sent to the server for saving. Ideally, what you see in the browser matches the records on the server. The problem is that if there is some mismatch, the project could break. And such mismatches could happen when there are problems with the communication between the browser and the server. I'm in a process of rewriting the whole website and eventually I will add different guardrails to prevent projects from breaking, but at this time projects are sometimes fragile.

My concern is when there are problems with the communication with the server. I'm still noticing slow moments from time to time. Not as bad as it was days ago, but still noticeable.

Otherwise I can suggest to reload the project more often. Personally I never experienced that moment when a project breaks, maybe because every time when something doesn't look right to me, I realod the whole page. But I probably do this because I know how a project could break.

You can try to give that constant data type of ENUM_MA_METHOD instead of int

@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 don't understand the idea here

.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.

Let's say that I don't understand your english. And my native language is not english by the way

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.

I have some feeling that you want to have moving pending order, something like trailing pending order. And there is a block for this - https://fxdreema.com/demo/mt4-trailing-pending-orders

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?

Pending order in fxDreema opens at different price than the current price. In the block you put the price and then the EA decides the type of the order. The easiest way... try with negative value for Price offset. But Open at price also matters... the combination of both is the actual open price.