Errors, bugs, questions - page 2180
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
Clearly, zero.
Is it OK to take 22 seconds to decide that there are zero bars in a given time frame?
Clearly an algorithmic bug in the internal implementation of Bars.
And I don't understand how you distinguish between zero bars in a given time frame and this zero:
From the documentation: If data for a timeseries with specified parameters when calling the Bars() function is not yet generated in the terminal, or timeseries data is not synchronized with the trade server at the time of the function call, the function will return zero value.
In other words, how can I distinguish between a null result and a null error?And I don't understand how you distinguish between zero bars in a given timeframe and this zero:
From the documentation: If data for a timeseries with specified parameters when the Bars() function is called has not yet been generated in the terminal, or the timeseries data is not synchronized with the trade server at the moment the function is called, the function will return zero.
The origin of zero is not important in this question, what is important is that this zero is born by the Bars function forever in the form of a couple of tens of seconds.
And I don't see how you can tell the difference between zero bars in a given time frame and this zero:
From the documentation: If data for a timeseries with specified parameters when calling the Bars() function have not yet been generated in the terminal, or timeseries data at the moment of the function call are not synchronized with the trade server, the function will return zero.
In other words, how can I distinguish between a null result and a null error?Think about it. If you had the task to create an analogue of the Bars function and were given an array datetime, the values of whose elements decrease with increasing number, in other words, the array is sorted.
Do you think it would be difficult to implement an algorithm searching for the number of elements of such a sorted array in a given time interval? And if there's not a single bar in the given interval or the array hasn't been initialized yet, we should return zero.
No - the algorithm is simple enough. What can it run for 22 seconds?
In this question, the origin of zero is not important, what is important is that this zero is born by the Bars function for ages, in the form of a couple of tens of seconds.
Precisely the origin is important, because if ::Bars() returned -1 instead of 0 (like now) in case of history error, no delay would occur. But now 0 is interpreted as an error and the delay is due to internal repetitions https://www.mql5.com/ru/forum/1111/page2200#comment_6955559
Moreover, suppose we introduce an additional check and the delay disappears. Then what happened? You've got zero. Is this a result or an error?
This is most likely due to history loading
The funny thing is that the first Print is processed without delay, i.e. history by H4 is already loaded.
And if you change CopyTime H4 to W1, there will be no delay at all. It means that history for W1 is already loaded too.
It's just that Bars gets inhibited by time interval between CurrentTime() and zero bar open time.
It's the origin that matters, because if ::Bars() returned -1 instead of 0 (as it does now) in case of a history error, there would be no delay at all. But now 0 is interpreted as an error and delay occurs due to internal repetitions https://www.mql5.com/ru/forum/1111/page2200#comment_6955559.
Moreover, suppose an additional check was introduced and the delay disappeared. Then what happened? You have got zero. Is this a result or an error?
It doesn't matter in all my algorithms whether the result of zero is a bar not hitting in the given interval or the absence of array as such.
You are leading away from the problem.
You're taking away from the problem.
I am stating the essence of the problem, you are fixated on your particular case. Judging by your previous post, you still don't understand when a delay occurs (that's besides the cause), although the previous page explains it all in detail.
Maybe this script can help you understand
I am stating the essence of the problem, while you are focused on your particular case. Judging by your previous message, you still don't understand when a delay occurs (this is besides the reason), although the previous page explains it in detail.
I have already formulated my opinion above as to when the delay occurs.
Once again:
Bars hangs up if start_time is in the range from the opening time of the zero bar of the requested TF to TimeCurrent(). (Just a hypothesis, but checked with practice)
Yes, the error occurs in a special case. But private cases should not be in standard built-in programming language functions.
And your "point" is not the point, because you are simply quoting the Bars command reference, which I am well acquainted with. There is no error code in the Bars function because it is not needed.
All the more so in this case we deal with fully formed arrays of timeseries.
This can be clearly seen in the slightly modified code of my script:
Result:
Maybe this script will help in understanding
Your script demonstrates this problem - hanging.
because the start_time - stop_time time range is within the weekly bar.
If you go outside the weekly bar, then there is no freeze:
Thank you for the clearer example
In MT4 CopyHigh, CopyLow functions (did not look at others) caused a critical error when there was no history in the tester. EA was tested on H1 and the request was from M1
1 15:14:35.410 2017.01.04 19:54:24 Access violation read to 0x0A971FE8 in 'C:\Users\Halyna\AppData\Roaming\MetaQuotes\Terminal\287469DEA9630EA94D0715D755974F1B\MQL4\Experts\____________.ex4'
3 15:14:35.465 2017.01.04 19:54:24 Testing pass stopped due to a critical error in the EA