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
Nonsense.
Nonsense.
As long as "suddenly" (c) there is no question of limited system performance (no matter which).
These days I've been looking more closely at OnCalculate and tick data handling. Earlier it was written that everything is done to avoid "freezing" of incorrectly written indicators, but if we really want to process the whole tick data flow since the previous call of OnCalculate, then at rapid price movement (and rollback) we should get a quite "deep" array, are there any limitations on the tick array depth?
I wouldn't like to hear an answer, such as "OnCalculate will receive an accumulating tick(s)..., to optimize...".
Who is already analyzing tick data, is there any reason for such concerns?
These days I've been looking more closely at OnCalculate and tick data handling. Earlier it was written that everything is done to avoid "freezing" of incorrectly written indicators, but if we really want to process the whole tick data flow since the previous call of OnCalculate, then at rapid price movement (and rollback) we should get a quite "deep" array, are there any limitations on the tick array depth?
I wouldn't like to hear an answer, such as "OnCalculate will receive an accumulating tick(s)..., to optimize...".
Who is already analyzing tick data, are there any reasons for such fears?
In 2008-2009 Renat once wrote that there is no happiness in ticks, he gave an example of an expert. Ticks are skipped anyway. If you need it, gethttps://www.mql5.com/ru/docs/series/copyticks on every call, but you will still miss the 50/50 top or bottom you want to enter.
I'll just pop in here for the sake of publicity. I've been trying to figure out why this stopped working for a month now:
Waiting for the new release on Opening.
Resuming questions related to optimisation and loading of historical data.
1. The problem of correct work of iClose/iOpen functions, and in this case iTime, exists and I think there is no sense to expect that everything will be perfect. Maybe they should be simply removed from MQL5 to avoid making the same mistakes again? (I have a problem, but I don't have time to describe it, because I have found a solution, another "twist")
Maybe there is a solution, but I would like it to be documented and not another MQL5 community twist. We are talking about how to deal with asynchronous requests, which in turn synchronize the local databases for example:
The key phrase is"After finishing synchronisation the next call of CopyTicks() will return all requested tick s. ", gentlemen how do you know when synchronization is finished??? It is written as if before the end of the synchronization CopyTicks() returns for example -1, but this is not the case. As a result after a few reloads indicator DB synchronizes and we're really getting the whole dataset, but if I'm not reloading indicator I'm not getting this dataset, because I don't know result of finishing this damn synchronization.
A striking example were the last knocks, there was a sharp movement on EURUSD, though the indicator was on all that time and sort of rendered this period normally, but after I had reloaded it (changed input parameters), the indicator started to reflect information incorrectly, respectively searches for errors in indicator were started (recompiled and reloaded several times) but nothing helped, and then that "miracle" happened, "Whenyou call CopyTick() from an indicator, it will immediately return the ticks available for the symbol, and also starts synchronization of the ticks base", maybe you should create (or have) function that can tell us that at the moment the synchronization of the local database is not completed, this function would ease our task and would allow us to write a better quality product for the Market.
P.S.: The SymbolInfoTick function unfortunately doesn't have this functionality.
Unfortunately, this example does not always work:
To be exact, it works 1-2 times out of 10 times.
But in the situation described above, it did not work even once.
Again a question, is the database updated in real time?
As I wrote above, the whole period that was problematic, the indicator worked, i.e. the CopyTicks() function was called regularly, but as it turns out it had no effect on the local database.... This is weird....
In 2008-2009, Renat once wrote that there is no happiness in ticks, giving the example of an expert. The ticks are skipped as it is. If needed, gethttps://www.mql5.com/ru/docs/series/copyticks on every call, but you will still miss the 50/50 top/trough you want to enter.
Resuming questions related to optimisation and loading of historical data.
1. The problem with correct operation of iClose/iOpen functions, and in this case iTime, probably exists and there is no reason to expect that everything will be perfect. Perhaps they can be simply removed from MQL5 to avoid repeating the same mistakes? (I have a problem, but I don't have time to describe it, because I have found a solution, another "twist")
Maybe there is a solution, but I would like it to be documented and not another MQL5 community twist. We are talking about how to deal with asynchronous requests, which in turn synchronize the local databases for example:
The key phrase is"After finishing synchronisation the next call of CopyTicks() will return all requested tick s. ", gentlemen how do you know when synchronization is finished??? It is written as if before the end of the synchronization CopyTicks() returns for example -1, but this is not the case. As a result after a few reloads indicator DB synchronizes and we're really getting the whole dataset, but if I'm not reloading indicator I'm not getting this dataset, because I don't know result of finishing this damn synchronization.
A striking example were the last knocks, there was a sharp movement on EURUSD, though the indicator was on all that time and sort of rendered this period normally, but after I had reloaded it (changed input parameters), the indicator started to reflect information incorrectly, respectively searches for errors in indicator were started (recompiled and reloaded several times) but nothing helped, and then that "miracle" happened, "Whenyou call CopyTick() from an indicator, it will immediately return the ticks available for the symbol, and also starts synchronization of the ticks base", maybe you should create (or have) function that can tell us that at the moment the synchronization of the local database is not completed, this function would ease our task and allow us to write a better end product for the Market.
P.S.: The SymbolInfoTick function unfortunately doesn't have this functionality.
What does SERIES_SYNCHRONIZED return in such cases?