The problem of transferring from MT4 to MT5. Or, more precisely, the inability to execute some algorithms in MT5 without'err. - page 7
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
The nonsense is in organising your own copy of the data, which is already available in the terminal.
There is a lot of such nonsense. When MT4 was released in August 2005, the ZigZag indicator appeared. There are a lot of errors there. In one instance it could hang the terminal on the fast market at that time. And it often displayed extrema in the air, not related to bar minimums/maximums.
In one post the developer of this zigzag said that this - (please take no emotion further) is a manifestation of fuzzy logic........
But until now, 14 years have passed since the launch of MT4, in the indicator of the zigzag there is a parameter - Deviation - which does not produce any action. That is, no matter what value of this parameter you set, the drawing of the zigzag on the chart will not change.
A lot of programs are based on this indicator. Most developers include this parameter in their programs. It is a useless parameter. The developers show a fantastic indifference to it. This parameter, by the way, eats computer resources.
There were many such moments on various other occasions.
I'll continue.
Those zigzag extremes hanging in the air are exactly of the same nature as what we have when accessing the timeseries.
It's just that access to timeseries was not denied in MT4. Some functions didn't work correctly there (maybe they still do now). I had an explanation for my own internal use. Also did a forced one on my own. And everything started working without errors, without CPU load. Even output of several dozens of zigzags on charts didn't cause the terminal to hang...
If everything worked, there wouldn't be a million topics devoted to this problem.
The logic just turned out to be more complicated than terminal users are willing to handle.
And there must be errors, but the developers don't have time to look for them, and no one wants to reproduce and prove them among the users either.
Andrei, I suggest we start with what we have. And since we have what you are talking about, is it better to talk about it, or to avoid it?
I think there are enough problems, but rather than talk about them from branch to branch (which is also useful - sometimes they get fixed), but do the workaround.
And I suggested a good option - to cache the necessary timeseries at the moment of their full availability. And then - get all necessary data from ready and always available timeseries. And only supplement them with new data. When they are available - slowly and not necessarily at the moment when you need them.
At least in this way things will move forward. And the conversations can be left for later - when there is nothing to do.
I'll continue.
Those zigzag extremes hanging in the air are exactly of the same nature as what we have when accessing the timeseries.
It's just that access to timeseries was not denied in MT4. Some functions didn't work correctly there (maybe they still do now). I had an explanation for my own internal use. Also did a forced one on my own. And everything started working without errors, without CPU load. Even outputting several dozens of zigzags to the charts didn't cause the terminal to hang...
If access to the timeseries is denied, it means that it is at the synchronization stage. You need to wait until the next tick.
In your situation - better to cache timeseries - they will always be available without waiting, and at the first request.
Cache when the indicator starts - when there is time to "wait for sync" and while waiting to request data for the next timeseries.
Andrei, I am suggesting that we should go with what we have. And since we have what you're talking about, is it better to talk about it, or go around it?
I think there are enough problems, but rather than talk about them from branch to branch (which is also useful - sometimes they get fixed), but do the workaround.
And I suggested a good option - to cache needed timeseries at the moment of their full availability. And further - to receive all needed data from ready and always available timeseries. And only supplement them with new data. At the same time, when they are available - not hurriedly, and not necessarily at the moment when they are needed.
At least in this way things will move forward. And conversations can be left for later - when there is nothing to do.
Then it's already more effective to make a reproducible example for the developers to fix.
Andrei, I'm suggesting that we should go with what we have. And since we have what you are talking about, is it better to talk about it, or go around it?
I think there are enough problems, but rather than talk about them from branch to branch (which is also useful - sometimes they get fixed), do the workaround.
And I suggested a good option - to cache the necessary timeseries at the moment of their full availability. And then to receive all needed data from ready and always available timeseries. And only supplement them with new data. At the same time, when they are available - not hurriedly, and not necessarily at the moment when they are needed.
At least in this way things will move forward. And conversations can be left for later - when there is nothing to do.
And why can't the developers of the terminal do that? There is no access to timeseries at the moment of updating anyway. Let everyone have access to this, let's say, cached history. What difference would it make? That is, so that there would never be an interruption in access. Well, maybe there would be some delays at the zero bar. The rest of the history would always be available.
I suggested a good option - to cache the needed timeseries at the moment of its full availability. And then - get all necessary data from ready and always available timeseries. And only supplement them with new data.
This is a bad variant, you have to repeat entirely the logic of building and synchronization of timeseries in the terminal - a new tick came, synchronization was not over... then a connection failure
ZS: Yes, and why do it? - I do not know how many in life, I have one mobile phone, one car, and even a wallet with only one, but a lot of cases in life? - need insurance? .... "Three tape recorders, three foreign film cameras, three cigarette cases domestic, jacket... suede... Three. Jackets" )))
If access to the timeseries is denied, it means it's in sync. You have to wait until the next tick.
You're right! But it's necessary to stop the MQL program at any place and exit the terminal until the next tick... I periodically suggest something like in Delphi "Abort() or Halt()" - get a time-series access error once - it'sa critical error, which makes no sense to handle many times - anyway, until the terminal can't adjust interaction with MQL-program "it's no use" ))).
SZZ: I don't create this error (timeseries access error) - it's created by terminal, but all MQL programmers should be ready to debug terminal generated error... ( when code consists of couple hundred lines ) it's easy to play with, but when the code is large and it's convenient to use timeseries access from different program sections - and it requires 999 ways to exit from any section and not to lose previous calculations? - Yes it is possible, but it requires a clear plan (algorithm) by which the source code will be written ... And if the source code is refined by adding ready-made functions (classes)? - i.e. every time you'll have to figure out what's inside... a generally time-consuming task for large projects to provide everything, imho
If a programme has been built for 14 years, translating it by new design method is easier than shooting yourself in the foot. And debugging the multiple links is also difficult. Checking accessibility to timeframes gives serious delays if there is no access. It would be fine if automaticgraphical constructions were enabled. Rebuild in automatic mode is an infrequent phenomenon. You may not even notice delays here. But in this case, too, when access to timeseries is interrupted, the graphical constructions are sometimes output in a truncated form. Some of the elements have time to be built and some of them do not... Or, fractal filtration truncates some tf.
***
If a programme has been built for 14 years, translating it by new design method is easier than shooting yourself in the foot. And debugging the multiple links is also difficult. Checking accessibility to timeframes gives serious delays if there is no access. It would be fine if automatic graphical constructions were enabled. Rebuild in automatic mode is an infrequent phenomenon. You may not even notice delays here.
But the problem is when adjustment is performed via graphical interface. The user presses the button and... has to wait for the next tick. Or the user presses the button several times until the desired response occurs. What is the user response...? -***
And there are no such problems in MT4.
I understand you very well, so I decided to support the discussion
iClose()...iXXX() functions to access timeseries - great!
May it be synchronous functions, i.e. time series access will be longer but guaranteed at the terminal level. Or U.V. developers should add the precompiler directive that will give a tick to MQL-program only if the terminal is ready to access historical data (OHLC) - no tick if not.
....
but the only purpose is to get rid of endless OHLC chart readiness checks, this problem has been solved since the appearance of MT5 only at the level of checks inside MQL program, it is a time consuming process and in my opinion the users expect the terminal to receive the time series data without any problems and guaranteed at any time, in any code section
this is a bad option, you need to completely repeat the logic of building and synchronizing timeseries in the terminal - then a new tick came, then the synchronization did not end...then a connection failure
ZS: Yes, and why do it? - I do not know how many in life, I have one mobile phone, one car, and even a wallet with only one, but a lot of cases in life? - need insurance? .... "Three tape recorders, three foreign film cameras, three cigarette cases domestic, jacket... suede... Three. Jackets" )))
All right! But the MQL-program must stop calculations at any place and exit the terminal until the next tick... I occasionally suggest something like in Delphi "Abort() or Halt()" - you've got one error accessing timeseries - it's a critical error, which makes no sense to process many times - anyway, until the terminal establishes interaction with the MQL-program "it's no use" ))).
SZZ: I don't create this error (timeseries access error) - it's created by terminal, but all MQL programmers should be ready to debug terminal generated error... ( when code consists of couple hundred lines ) it's easy to play with, but when the code is large and it's convenient to use timeseries access from different program sections - and it requires 999 ways to exit from any section and not to lose previous calculations? - Yes it is possible, but it requires a clear plan (algorithm) by which the source code will be written ... And if the source code is refined by adding ready-made functions (classes)? - i.e. every time you'll have to figure out what's inside... ...time-consuming task for big projects, imho
If the program is executed by a mouse click, it doesn't matter whether there is an access or there isn't one - you have to react. You can write a lot about how badly everything is done, but in this case it is better to have your own cache, from which you can always access on demand.
Just imagine the program, which instead of giving something on the long calculated historical data by mouse click, says - go for a smoke - I get the current data, which you do not need now, and rebuild the timeseries...
No matter what, if you have to make do with what you have, it's better to give out what's in the cache and then rebuild it after unlocking time-series access.