![MQL5 - Language of trade strategies built-in the MetaTrader 5 client terminal](https://c.mql5.com/i/registerlandings/logo-2.png)
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
Think about where the data (the more so it is guaranteed) will be available, when your indicators tremendously slow receiving/laying ticks, spending hundreds of milliseconds or even seconds for one tick. As a result, no CPU is sufficient in time to process 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.
Let's leave only one tick (a new bar) for the new type of data processing by the indicator in the proposed version. Those who like multiple recalculations of zero bars and the grail in the zero bar should enjoy the existing version. Add a new function to OnInit - iOnCalculate - a handle to one of the TF functions / OnCalculate in the indicator, like iCustom, but it is a little closer, the indicator buffers on OnCalculate should be bound to the handle iOnCalculate. In the indicator functions like OnCalculate, send only a new tick bar. For the terminal, nothing will change, the basic logic of OnCalculate will be the same, the main body of the indicator will be added, for example OnMain. (Now everything is done by the indicator(s), attached to the main indicator as a resource and called from it on a new bar).
You don't always need super speed, usability is also very important, nowadays writing multicurrency indicators is like "setting the sun by hand", even in MT4 it was easier, because you could always get it through i-functions, even if slowly, but you could get it, but in MT5 you can either get it or not, and you still need to make a special code yourself.
Let's skip the theories.
Just submit an example to be reproduced and we'll see what horror is around your case. So far it looks like a total disregard for performance, hiding killer retard indicators and trying to cast a shadow.
Let's skip the theories.
Just provide an example to reproduce and we'll see what horror surrounds your case. So far it looks like a total disregard for performance, hiding the killer retard indicators and trying to put a shadow over it.
The example in the attachment, it is not the finished code, it is incomplete in some places, but it is possible to run it, I am also attaching a template for convenience,
i will tell you right away, i am not a programmer, for sure the code is not optimal, i am a humanitarian economist, i really suffered in MT5, i suffered less in MT4,
I really want a simple and reliable function that would build a synchronized array as described above https://www.mql5.com/ru/forum/289897/page2#comment_9363454.
I'm not complaining, I'm not asking to write my indicator, I just want (not only me by the way) a nice standard function.
EDIT: corrected the attachments
Do as I advised, please.
Otherwise you need full materials for 100% playback.Your attitude to bug reports is strange. It's not like I'm paid to prove anything. I described the situation as best I could.
I'm not the only one with this problem. This problem occurred after your 30th update, but still you insinuate that I am an idiot and some slow-moving indicators are to blame.
Weren't they slow for a year before that?
Here is an example of code which hangs after 25 minutes on M30:
And here's the result:
The example in the attachment, it is not yet complete code, in some places not written, but you can run it, I am also attaching a template for convenience,
i can promise that i am not a programmer, for sure the code is not optimal, i'm a humanitarian economist, i really suffer in MT5, i suffered less in MT4,
I really want a simple and reliable function that would build a synchronized array as described above https://www.mql5.com/ru/forum/289897/page2#comment_9363454.
I'm not complaining, I'm not asking for trouble,
I'm not complaining, and I'm not asking to write my indicator for me, I just want (not only me by the way) a nice standard function.
EDIT: corrected the attachments
Your attitude to bug reports is strange. It's not like I'm paid to prove anything. I have described the situation as best I could.
What I wrote earlier in this thread does not qualify as a bug report in any way.
All went on the pattern of complaints without any technical details. It was only after my enquiries that the details started to emerge.
Your attitude to bug reports is strange. It's not like I'm paid to prove anything. I've described the situation as best I could.
The problem is not only me, the problem appeared after your 30th update, but still you insinuate that I am a fool and blame some retarded indicators.
Weren't they slow for a year before that?
Here is an example of code which hangs after 25 minutes on M30:
And here's the result:
Uploaded
It's now 18.10 Everything is working.
The example is attached, it's not yet complete code, it's underwritten in some places, but it can be run, I'm also attaching a template for convenience,
I'll show you the code and the work at once:
It's necessary to change to a gentle mode "I will carefully wait for successful downloading". For example, OnCalculate is not called.
In this case the update of charts of this symbol is blocked and many other participants have to wait and not receive fresh data. The indicator should not take resources for a long time. It's better to stretch the long initialization step by step/symbol initialization in OnCalculate, counting step by step.
Your attitude to bug reports is strange. It's not like I'm paid to prove anything. I've described the situation as best I could.
The problem is not only me, the problem appeared after your 30th update, but still you insinuate that I am a fool and blame some retarded indicators.
Weren't they slow for a year before that?
Here is an example of code which hangs after 25 minutes on M30:
And here's the result:
I put the code to work. So far so good.
A file without a body, by the way.