MQL5 bug when working with iClose/iOpen timeseries access, etc. - page 2
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
Then tell me why freezing happens in my case? I have freezing of data in OnTick before indicator polling function, i.e. CopyTime update by M1 acts as a trigger to start other processing in OnTick, and before CopyTime no functions or indicator polling.
And why there were no such problems before 30th build and since October 2017 everything was working fine ?
Do as I advised please.
Otherwise need full materials for 100% playback.Why don't the developers write a function that guarantees a synchronized array of data (across several tools) so that people don't bother and waste their time in vain?
after all MT5 is positioned as a cool and handy tool, right?
very much looking forward...
It has also always been recommended that if you work with someone else's timeframe - you should get OHLC from that timeframe once a minute (any CopyXXXX function). This has always been the case.
Slava said once every two minutes. Lazy to look for it, but I remember exactly.
Why don't the developers write a function that guarantees a synchronized array of data (across several tools) so that people don't bother and waste their time?
after all MT5 is positioned as a cool and handy tool, right?
we are waiting...
Yes. OnCalculate constructor for required number of symbols and timeframes. Or, in addition to OnCalculate, introduce a new object, for example "MainCalculate" for maximum 255 OnCalculate, in which OnCalculate objects live - who doesn't need it, uses the old one OnCalculate, who needs mtf and different symbols uses "MainCalculate". The first and the last tick of the bar is the same for all symbols and matching timeframes. Because OnCalculate has already been developed and established, it is logical to output all calls to third-party symbols and timeframes through OnCalculate aggregation without other functions mediating to timeframes and symbols.
Think about where the data (especially the guaranteed data) will be available when your indicators are unbearably slow, taking hundreds of milliseconds or even seconds to receive/layout ticks per tick. As a result, no CPU is sufficient in time to process the ticks, which translates into an accumulating deficit and a corresponding stall in the chart history.
When you ask for "guaranteed give", it is most likely a request of "don't want to know anything, want to keep writing as I want, don't want to think about performance and locks, just give"?
When you have millions of bars available to you, think about the performance of your and other people's indicators. A poorly written and expensive indicator can easily slow down the updating of its symbol charts.
For starters, start measuring in microseconds the response time of OnCalculate. Then divide 1 second by the average tick response time to get the maximum breakdown of the indicator in ticks per second.
This is immediately sobering.
Every two minutes, Slava said. I'm too lazy to look for it, but I remember exactly.
I remember, but I always use a 1-minute interval. It's more reliable that way.
Excuse me, but in this case the depth of history on M15 timeframe was 120 bars and what, is it already critical for MQL5?
You have not provided any reproducible material.
I have explainedwhy the functions of accessing other people's data will be retarded when there are retard indicators on their symbols. You are talking about your particular case of call, completely ignoring the presence of other indicators on the charts. And they are the ones you should have started with, especially since I clearly write about it.
Don't engage in demagoguery and comparative statements with a complete lack of technical deeds and lists of indictors with experts.
Give me the code to reproduce, please.
***
So how do you play it back? Please give me the data for playback.
Of course I can't put the whole code here, but I've already pointed out the part where the problem occurs, so I'll do it again:
Either the whole code or don't say anything. Without the full code, it's just a lot of air.
Think about where the data (the more so it's guaranteed) will be available, when your indicators unbearably slow receiving/applying ticks, spending hundreds of milliseconds or even seconds for one tick. As a result, no CPU is sufficient in time to process the ticks, which translates into an accumulating deficit and a corresponding stall in the chart history.
When you ask for "guaranteed give", it is most likely a request of "don't want to know anything, want to keep writing as I want, don't want to think about performance and locks, just give"?
When you have millions of bars available to you, think about the performance of your and other people's indicators. A poorly written and expensive indicator can easily stall chart updates of its symbol.
Start by measuring the OnCalculate response time in microseconds. Then divide 1 second by the average tick response time to get the maximum tick throughput of the indicator in ticks per second.
This is immediately sobering.
You don't always need the super speed, the usability is very important, nowadays the process of writing multicurrency indicators is like "sunset by hand", even in MT4 it was easier, because there you can always get it through i-functions, even if slowly, but you can get it, but in MT5 the data is either there or not, and you need to create a special code by yourself.
Also, you should keep in mind that not all users are high-class programmers, some people just need a convenient and reliable tools, even if it is not supersonic, and such speed is not usually needed for portfolio systems, and the maximum throughput is not critical in this case, the important thing is that it works guaranteed and easy, in fact, this is the factor to make the product more popular and accessible.
The appearance of i-functions in mt5 has somewhat improved the situation, but it hasn't solved the problem, there is no possibility to easily and simply get a synchronized array for several instruments, maybe it's not necessary for everybody, maybe it's not even a priority, I can understand it, but nevertheless there is such a task.
Function: GetSyncData
Input: list of symbols, timeframe, bar range and/or date range
Output: array with MqlRates elements so that indexes of all symbols correspond to the same time