[SERVICE DESK] Error in getting the time of the senior TF in the timer! - page 15
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
Your indicator does not track the data update.
New bars are coming from the broker and you don't check them.
I've added a couple of lines to show that when you check, everything is displayed correctly.
It's a working situation - checking out the new bar.
You don't say! What makes you think that I have to keep track of new bars? Is it written in the documentation? I mean that I MUST obtain the value of the function, and then I must necessarily compare it with the previous value? There is a function, the function is designed to work with high timeframes. The function may return an error when it has no data, or return an incorrect value (equal to 0 in this case). That's all. The programmers do not have to do anything to get a 100% correct value.
But look what I found in the documentation for SeriesInfoInteger():
To get more information about the error, you need to call GetLastError() function.
And you look at my very first post. Do you see error 4066 there? Then error 0 and return incorrect data. Why doesn't the function (in this case, SeriesInfoInteger()) check for relevance before sending the data? Why doesn't it set the error flag? You see, I'd rather wait a bit longer for internal checks to pass than look for errors later.
But after that I've been given a lot of advice, with which I still haven't got any result. And it turned out it wasn't even about the timer.
Ok, read the help)
SeriesInfoInteger
Returns information about the state of historical data.
The word historical means what?
If history is loaded - there is no error.
No way! And what makes you think that I should necessarily track new bars? Is it written in the documentation? I mean, I MUST get the value of the function, and then I must necessarily compare it with the previous one? There is a function, the function is designed to work with high timeframes. The function may return an error when it has no data, or return an incorrect value (equal to 0 in this case). That's all. The programmers do not have to do anything to get a 100% correct value.
But look what I found in the documentation for SeriesInfoInteger():
In my code see GetLastError()? Here is a check. This check must be necessary and REAL! All the rest are crutch solutions.You don't have to do anything).
...broker sends you updated data - if you want, use it for calculation, if not - no problem, use the existing history.)
ps. it's the weekend, the market is closed, you have incorrect data in your terminal!
and there is no error!!!)
ok, read the help)
What does the word history mean?
If the history is loaded - there is no error.
You do not owe anything.)
...the broker sends you updated data - if you want to use it to calculate, if not - no problem, use History)
Every tick that comes into the terminal is already a story. And I want to get its actual values or error. If that suits you - ok.
Every tick that comes into the terminal is already a story. And I want to receive its actual values or error. If that suits you, that's fine.
Yes, the history is what has already been downloaded or what is being downloaded in the past.
And what is updated only now (after the last quote) is not the history, it is the new raw data.
Check the candle time, not the calculation of the bars.
This is how it will update correctly (checked).
Taras, here is the result of your code:
Taras, here is the result of your code:
Yes, it's the first tick, the one that produces the finished story, the one that is available.
After this tick (if there are new bars), immediately comes the second tick, in which my code updates your variables and they show the correct data.
ps. you can insert your own function to check the new bar, it will be the same.
I, myself, constantly check the number of bars, if the number has changed by more than 1, it means you need to recalculate everything again, if the number has changed by 1, it means just a new bar. And I check only the most critical errors, and I don't see this delay-error.
Yes, this is the first tick, the one that gives the ready history.
After this tick (if there are new bars), immediately comes the second tick, in which my code updates your variables and they show the correct data.
If the number has changed by more than 1, then it's just a new bar.
I, myself, constantly check the number of bars, if the number has changed by more than 1, it means you need to recalculate everything again, if the number has changed by 1, it means just a new bar. And I check only the most critical errors, and I don't see this delay-error.
And here, by the way, is another argument in favour of the error happening. It is ERROR in calculation in the indicator! I wrote an Expert Advisor:
Runs from the same chart as the indicator. Let's see the results:
What we see. We see that everything is fine. All loaded, and note that there are no errors, the data is immediately updated! The main question is why the GMT data can be obtained normally, while the indicator should "play with diamonds"? Shouldn't the programs work equally? Why the same code works differently in an indicator and in an Expert Advisor? This should not be the case.
And here, by the way, is another argument in favour of an error occurring. It is the ERROR in the calculation in the indicator! I have written an Expert Advisor:
Runs from the same chart as the indicator. Let's see the results:
What we see. We see that everything is fine. All loaded, and note that there are no errors, the data is immediately updated! The main question is why the GMT data can be obtained normally, while the indicator should "play with diamonds"? Shouldn't the programs work equally? Why the same code works differently in an indicator and in an Expert Advisor? This should not be the case.
All indicators are in a single thread, and nothing new will happen until the end of the flow (in fact, until the next call of Opsalure). Expert Advisor is in its own separate thread, so when it starts, it is allowed to postpone its startup for data updates, update data - everything else in the terminal is unaffected. It has been like this since birth and there is no way to fix it, as the metatrader4 environment has been buried.
Because it's up to terminal to connect and do something with loading, checking, etc., all indicators are in one thread, and nothing new happens until everything in the thread ends (in fact, until the next call of OpCalculate), i.e. being in this thread, you will not get anything faster than the end of the thread anyway. Expert Advisor is in its own separate thread, so when it starts, it is allowed to delay its start for data updates, update data - everything else in the terminal is unaffected. It has been like this since birth and there is no way to fix it, because the metatrader4 environment has been buried.
I am aware of the fact that all indicators of one symbol are in one thread while each expert has its own thread. But this is not the case. The developers are the very developers who fix errors in their creations. Programs should not work differently! If the indicators have missed something, it is an error and there is no problem. The Expert Advisor has somehow received the correct data without errors! So we can implement it. @Slava, can you give your opinion on whether the obviously erroneous behavior will be corrected? Or, at least, documentation addition (that with prev_calculated = 0 no correct data of senior TFs can be obtained)?
Yes I am aware that all indicators of one symbol are in one thread, and a different thread is allocated to each expert. But this is not the case. The developers are the developers who fix errors in their creations. Programs should not work differently! If the indicators have missed something, it is an error and there is no problem. The Expert Advisor has somehow received the correct data without errors! So we can implement it. @Slava, can you give your opinion on whether the obviously erroneous behavior will be corrected? Or at least, will it be added to documentation (when prev_calculated = 0, we cannot get correct data of senior TFs)?
The documentation says that Expert Advisor has as much as 5 seconds before start to receive data and during this time the terminal tries to receive data for the Expert Advisor. The indicator is not given such a possibility and the same way it should not request history refresh, it is not critical for it, if it is critical, then it must be calculated in an Expert Advisor. The main idea is that the desired situation is not possible in the current implementation. Basically, TFs are timers and there are periods where these multiple timers coincide at one moment - this is 100% coincident synchronous process (except opening/closing time), because the first tick of a minute of the current TF coincides with the first minute of five-minute, hour etc. - it is just writing the same value in several variables, and it is logical to set a set of needed TFs and get all necessary data at once. Why developers have done so and not vice versa, I do not know. Maybe, it cannot (will not) be done in the existing terminal operation model because of the client-server division, as if we now allow experts to use indicators, they will hang the terminal.
You may see at the end of the day, if you are interested, how indicator call works, indicator calls another indicator, expert(_asktfexp) calls indicator(_asktf_sample) calling indicator(_asktf). When calling an indicator from an expert, the timer in the indicator will not start, so solutions with a timer in the indicator are only for cases where this indicator will only hang on the chart and will not be called (which is logical in general).