Errors, bugs, questions - page 3030
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
we return 0, thereby stating that we have not yet counted anything and will not increment by 1 on the next bar.
i.e. we will be on the bar where we started the request for data from the olderfactor until we return(rates_total)
From the help:"The prev_calculated parameter on function call contains the value returned by OnCalculate() onthe previous call."
Yes, there is a lot written in the Help, but it is not always clear, unfortunately (not to spite the developers), you have to learn, learn, learn. But this branch exists because sometimes things are discovered that are not consistent with either the Help or common sense, A100 is our hero, because it goes even where no one would climb on their own)).
1. Thank you all - I have become a little more literate in indicators ))))
Andrew, if someone doesn't understand your ideas (including me), it means only one thing: YOU don't draw the picture correctly! Or rather, you do it in such a way that many people do not understand it ...
the truth is more important. it is not always clear to everyone, unfortunately.
Andrey Dik:
returns 0, thereby stating that we have not yet counted anything and prev_calc will not be incremented by 1 on the next bar.
Then return(rates_total) should increase prev_calc by rates_total?
returns 0, thereby stating that we have not yet calculated anything and the prev kalk will not increase by 1 on the next bar.
he himself zeroes in on the calculation and complains that he zeroes in on it )
we can afford to calculate a new bar only once and not on every tick.
we cannot afford to because the terminal will not generate historical data online on the "higher TF"
in general, some assumption is needed here:
- either we construct OHLC inside the indicator by ourselves
- or the terminal builds OHLC for us itself
If it is the latter, then we should consider that the terminal does not know at all how TFs interact, who is a multiple of what and what happens upon the"new bar" event but we should let the terminal build the necessary TF
Try this code in your second indicator:
himself resets the calculation and complains that it resets )
Andrei, run the code, please... but don't you start, eh? I can't fight you.
we cannot afford as the terminal will not generate historical data online on the "older TF"
in general, some assumption is needed here:
- Either we construct OHLC inside the indicator by ourselves
- or the terminal builds OHLC itself
if it is the latter, then we need to consider that the terminal does not know how the TF interacts, who is a multiple of what and what happens upon the"new bar" event
Try this code in your second indicator:
Your code will make calculations on every tick, it's not interesting for me, I'm not even going to run it. I need to do the calculation only ONE time on each bar, on all used indicators, not on each tick of all used indicators.
Your code is going to hammer out calculations on every tick, I'm not interested, I won't even run it. I need to do the calculation only ONE time on each bar, on all the indicators used, not on each tick of all the indicators used.
My code will "tick by tick" only your indicator #1, where you have written :
it will allow the terminal to build the "higher timeframe" by itself.
For me - it's "cheaper" than to perform a complete recalculation of the indicator № 1, that happens in your code when synchronizing the history on the "older TF
Andrei, would you run the code, please... but don't you start, eh? I can't fight you.
Replace
to
and test it.