prev_calculated - page 8
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
Oh dear, how do you think a bug is different from an axiom? No need to sprinkle your brains with words here - all formulated in 3 paragraphs can be easily seen in my 1st post. If it is not so - you are a programmer, not a carpenter, show in your code how to solve separately simple tasks listed in 3 paragraphs with bare prev_calculated without additional crutches: show how many bars were counted on the previous tick, define first call of OnCalculate and define that the history (checksum) has been changed. There is no need to make anything up for the user, to fit your axioms - the tasks are formulated, very simple and unambiguous as half a finger
This question should not be addressed to Vladimir (he only defends the developers' position), but to the developers themselves, who (represented by Slawa) said that when prev_calculated = 0 - recalculate everything again. They cannot always calculate all variants of the indicator use. If there is a problem now, it is useless to torment the moderator, you must go to servicedesk with a detailed description.
There's no point - MQ has a master list of development priorities, and the desires of passengers don't bother the driver. The optimal solution for passengers is to get themselves a moped. As it was with the homemade prefix object removal functions before MQ's priorities got around to it. That's what I suggest to Vladimir, as the chief enthusiast of Five - to make a nice function that would bag the flies and cutlets separately, but he stubbornly dodges it. If function/structure shows how many bars were counted at pre_calculate, plus 2 flags - 1st run OnCalculate and change checksum, user will decide how to live - when to initialize, recalculate or sleep. And bare prev_calculated as it is solves a private combination of 3 "ifs" - this is a rake for user
There's no point - MQ has a master list of development priorities and the needs of passengers don't bother the driver. The optimal solution for passengers is to get themselves a moped. As it was with the homemade prefix object removal functions before MQ's priorities got around to it. That's what I suggest to Vladimir, as the chief enthusiast of Five - to make a nice function that would bag the flies and cutlets separately, but he stubbornly dodges it. If function/structure shows how many bars were counted in pre-call, plus 2 flags - 1st run OnInit and change checksum, user will decide how to live - when to initialize, recalculate or sleep. And bare prev_calculated as it is solves a private combination of 3 "ifs" - this is a rake for user
The point is to at least put the problem "in writing". If they appreciate it, at least put it on the list.
In the meantime, you have proposed a normal solution, perhaps not a very pretty one, but the problems you are solving are not exactly standard.
There is no point - MQ has a mainstream list of development priorities, and the passenger wishes of the driver don't matter. The optimal solution for passengers is to get a moped. As it was with the homemade prefix object removal functions before MQ's priorities got around to it. That's what I suggest to Vladimir, as the chief enthusiast of Five - to make a nice function that would bag the flies and cutlets separately, but he stubbornly dodges it. If function/structure shows how many bars were counted in pre-call, plus 2 flags - 1st run OnInit and change checksum, user will decide how to live - when to initialize, recalculate or sleep. And bare prev_calculated as it is decides a private combination of 3 ifs - it's a rake for the user
To a question about buffer initialisation during initialisation. Consider logically. There is no access to rates_total in OnInit(), right? If there is no access to rates_total in OnInit(), then the sizes of indicator buffers are not known yet ( =0 you can check yourself ). And since an indicator buffer size = 0, what are you going to reset?
You should not address this question to Vladimir (he only defends the developers' position), but to the developers themselves (represented by Slawa), who told you that when prev_calculated = 0 - recalculate everything anew. They cannot always calculate all variants of the indicator use. If there is a problem now, it is useless to bother the moderator, you must use the service desk with a detailed description.
If he had not tried to give clumsy advice, nobody would have tormented him.
No answer pretends ... ...and tries to make people look the same...
1. Again a stream of thought, but I never saw the point.
2. You still haven't answered the question, which shows that you have never thought about what is stored in the variable after it is declared.
Don't pretend... All clear, but especially for you a picture
The computer was working without shutting down, the chart was not closed, the indicator was not removed from the chart...
Question: Where did the 2 minute bars disappear to?
That's understandable. What's insane is that Vladimir says that the indicator buffer should be cleared in the loop over all elements of the array...
Don't pretend... All clear, but a picture especially for you
The computer was working without shutting down, the chart did not close, the indicator was not removed from the chart...
Question: Where are the 2 minute bars missing?