
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
Vladimir, the problem doesn't occur in the tester... How come there is such a problem? Or because there is only one Expert Advisor in the tester?
I also suggested in the SD that the only change was putting the second EA on a different pair...
In one terminal (on M15 timeframe there were EAs) it didn't work on one symbol - I'm 99% sure that the problem is that when using someone else's timeframe you need to "jerk" the history all the time. I think it's better to do it via CopyTime().
This is not a mistake. You are working on someone else's timeframe. In such a case, you have to take care of the data on someone else's timeframe yourself to ensure that it is up to date.
I personally do not see any alternatives.
It is not a fact that we do not know howSERIES_LASTBAR_DATE works. It may be that there is no need to update anything because the time of the last bar can be calculated using TimeCurrent() of the specified symbol. We need to ask the developers.
But so far a clear indisputable fact is that if two variables are set true, then together (when checking &&) these variables will also give true.
The problem with the other tools/TF cache dropping off does exist.
Checking for errors and waiting in loop to load does not always help. We have been talking to Service Desk, but MQ has not made any progress, only one hint:
The suspicion is that the historical data is unloaded by timeout.
There are 2 solutions:
1. access the data more often than once every 3 minutes
2. Put some very simple indicator on data. Volume, for example. There is no calculation, only one buffer is busy. Availability of indicator will keep historical cache in memory regardless of access frequency
The 2nd tip does not work, indicators are called all the time, but at some point the cache fails and it becomes impossible to get data.
I solved the problem with this crutch - I call this code every 150 seconds for all involved instruments/FTs:
Works fast enough, error 4806 seems to disappear after this update.
Please comment on another misunderstanding.
Bars
Returns the number of bars in the history by the corresponding period symbol. There are 2 variants of the function.
Only the second option is of interest.
Expert Advisor text
I understand that the time 00:00:00 belongs to the day, just like the time 00:00:01
But ... the proposed prints do not agree with that.
It turns out that between 2016.06.22 00:00:00 and 2016.06.24 00:00:00 there are three daily bars and between 2016.06.22 00:01 and 2016.06.24 00:00:00 there are only two...
Or am I misunderstanding something???
And if you add a second to the time of the current bar
you get the following
The time 2016.06.24 00:00:01 seems to belong to the next bar or what?
The upper time limit is not included into the interval in which the number of bars is determined.
Dimitri, isn't that strange? A new bar has appeared, but we will not count it yet.
Listen, isn't it the reason for such behavior of the SeriesInfoInteger(_Symbol, PERIOD_D1, SERIES_LASTBAR_DATE); ? New bar appeared, tick available code is executed, but time is not yet taken into account???
Well, the drummer's deflated... And he's gone completely ignored...?
Vladimir, can you at least answer this question???
Does CopyRates() pull the story? There is time in the structure...?
Well, the bogeyman has deflated... And he's been totally ignored...
Vladimir, can you at least answer this question???