
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
Once again. It doesn't say that anywhere. That's first of all. Secondly, why is it then misleading by first showing an error code 4066 and then not?
The data are pumped in batches and then processed by the terminal, and since you're working on a timer, you are paused. I don't see it explicitly anywhere but many programmers writing MTF applications usually know about it and I've told you about it at once.
https://docs.mql4.com/ru/series/timeseries_access read it thoroughly.
Well, above you already gave us a variant of checking history accessibility. It is not perfect but it is simple and obvious.
If this variant does not work, check as follows.
The data is pumped in portions and then processed by the terminal, and since you are on a timer, you get paused. Yes, it's not explicitly mentioned anywhere, but many programmers who write MTF applications usually know about it and I told you about it right away.
https://docs.mql4.com/ru/series/timeseries_access read it thoroughly.
Well, above you already gave us a variant of checking history accessibility. It is not perfect but it is simple and obvious.
About getting "into a pause", where are the proofs?
I read it carefully (and have read it before). I am aware that data (especially older TFs) is not always immediately available. No problem. But why then does the SeriesInfoInteger() function return no error!? Here is the question!
Assuming that the request falls on some pause/swap/update/break etc., then let it return error code != 0. And there won't be any problems!
And above you have already given the option of checking the accessibility of the story. It's not perfect, but it's simple and straightforward.
Answered above @Ihor Herasko on this point.
Answered @Ihor Herasko above on this point already.
I gave my version of the test above. Why so question to the developers but this point has been known for a long time!
I will certainly try your version of the test and report the results.
I will certainly try your version of the test and report back with the results.
First a reply from @Ihor Herasko. Code for playback:
Result:
According to the log entries. The terminal was switched off at 14:25. Next, switched on at 14:30. We check the time of bar M15. We started with TF M1. The indicator (code above) showed actual open time 12:15 (terminal time, lagged behind my local time by 2 hours). The result should have been 12:30! Conclusion - the error is present. And this method suggested by @Ihor Herasko does not work.
Make sure to report back! It works for me! But there may be all sorts of pitfalls if it does not work we will think what else we can do.
I'll sign off. Code:
Result:
Turned the terminal off at 2:48pm, turned it back on at 3:01pm. Should have gotten the time at 1:00 p.m. I got 12:45. Any other questions?
I changed TF from M1 to M5 and got correct result:
I think I've got it! Is the indicator started immediately with the terminal? If so, before checking wait for a connection to the server IsConnected() you have a very fast timer it does not have time to synchronize!
Or do this
But you have to take into account the difference between server time and local time. Write back with the results!