Errors, bugs, questions - page 2179
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
No, it has nothing to do with loading.
If you don't take a zero starting bar, but say 50 bars, then everything is OK. Instantaneous.
And if I take it up to and including 30 bar, it freezes. After that, it doesn't.
IT'S DEFINITELY A BUG!
Try this one:
Try this one:
What does iBarShift have to do with anything?
It's about a bug in the standard Bars function
What does iBarShift have to do with anything?
It's about a bug in the standard Bars function
That function also uses Bars(). You started with the analog of iBarShift()
That function also uses Bars(). In your case, it all started with iBarShift()'s analog
Yes, of course, using the iBarShift counterpart revealed this problem.
If you use iBarShift function given by you, you won't catch this bug, because only one TF is used there,
And this bug happens when you use different TF in CopyTime and Bars functions.
But Bars should work normally for any time. But my example shows that there is a special case, where iBar hangs for tens of seconds. And it has nothing to do with loading history.
Yes, of course, using the iBarShift counterpart revealed this problem.
If you use iBarShift function given by you, you won't catch this bug, because only one TF is used there,
And this bug happens when you use different TF in CopyTime and Bars functions.
But Bars should work normally for any time. But my example shows that there is a special case, where iBar hangs for tens of seconds. And it has nothing to do with loading history.
This is most likely due to history loading
Yes, of course, using the iBarShift counterpart revealed this problem.
If you use iBarShift function given by you, you won't catch this bug, because only one TF is used there,
And this bug happens when you use different TF in CopyTime and Bars functions.
But Bars should work normally for any time. But my example shows that there is a special case, where iBar hangs for tens of seconds. And it has nothing to do with loading history.
I think there is an attempt of cyclic sync in a situation where there are no bars in the requested range - Bars is trying hard to "work normally" and then gives up by a timeout or number of attempts at sync.
You should check the values yourself to avoid calling Bars in such a case.
This is most likely due to history uploading
I disagree. It would not have been downloaded again for 22 seconds. Moreover, I have all the history for all TFs loaded by a special indicator.
If it was a loading, then how can we explain that the first 31 bars need loading and the next ones do not.
If it were a sub-loading, then how do you explain that the first 31 bars need a sub-loading and the subsequent ones do not.
From the documentation: When requesting the number of bars in a given date range, only those bars whose opening time falls within this range are taken into account.
Accordingly, the Bars() prototype returns zero, which is interpreted as no history and ::Bars() in the case of the script, as correctly noted in a previous post, terminates by timeout or by the number of failed attempts.
I think there is an attempt of cyclic synchronization when there are no bars in the requested range - Bars is trying hard to "work normally" and then gives up by timeout or number of synchronization attempts
The reason of such cases is that you should not call Bars in order to check the values yourself.
It is quite possible.
But there are plenty of options.
Bars is a very important function, and it's hard to do without it. To be exact, you can do without it but it will cost you a great deal of resources.
You must make sure that it functions perfectly.
From the documentation: When requesting the number of bars in a given date range, only those bars whose opening times fall within this range are taken into account .
Accordingly, the Bars() prototype returns zero, which is interpreted as a lack of history and the script, as correctly noted in a previous message, terminates by timeout or number of failed attempts.
It is clear that it is zero.
And what - is it OK to take 22 seconds to decide that zero bars in a given time range?
There is an obvious algorithmic bug in the internal implementation of Bars.
We should send a request to Service Desk on this subject - the weekend is ahead and the subject might get lost on Monday.