Errors, bugs, questions - page 3035
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
An error appeared on the freelance jobs pages today:
Chrome browser. What does this have to do with it?
Thank you for your message. Corrected
Can't you check it yourself?
You can check it, but what is there to check when there is no understanding ))
And it is not possible to simulate the moment when the data is not ready yet.
I want to understand the theory, how to work correctly with OnCalculate in this example.
If data is not ready at current loop iteration, should the limit+1 counter be returned or what?
It is possible to check it, but what is there to check when there is no understanding)
And it is not possible to simulate the moment when the data is not ready yet.
I want to understand the theory of how to correctly handle OnCalculate in this example.
If data is not ready at current loop iteration, should the counter limit+1 be returned or what?
Zero should be returned.
4. All timeseries are processed in order, from the lowest to the highest. First the application of the tick, then the calculation of all the indicators created on that timeseries. If you are asking for data for the same H1 symbol from an indicator, working on M1, you will never get data with an applied tick. The data will always be one tick back, no matter what tricks you apply. Because one thread per symbol with consecutive processing of timeframes.
The statement is a bit ambiguous. Let me clarify it just in case. Yes, when processing a tick, all timeseries are processed in sequential order, from the youngest to the oldest. Each tick is added to data of each timeseries, then indicators are calculated for each timeseries, in order. In other words, for the indicator in OnCalculate(), the data of the time series (all of them) is certainly updated, but the data of the indicators of the older timeframes hasn't been recalculated yet.
At the first request, the indicator may not receive data from its symbol but another timeframe only for one reason - the required timeseries has not yet been built or has already been destroyed after some time, when there were no requests.
After an unsuccessful request, just send a command to your chart to update it and terminate OnCalculate immediately. It's guaranteed that OnCalculate will be called and it's guaranteed that the needed timeseries will be prepared by this time.
This is like using a hammer to catch a fly.
As you know, this command updates all indicators on all charts of the symbol in question. If you have several indicators on several charts of the same symbol, you can easily get a kind of cycle, because each indicator will send its own ChartSetSymbolPeriod () command.
Could you add a command to update only the REMOTE indicator?
This is similar to using a hammer to catch a fly.
As you know, this command updates all indicators on all charts of the symbol in question. If you have several indicators on several charts of the same symbol, you can easily get a kind of loop, as each indicator will send its own ChartSetSymbolPeriod () command.
Could you add a command to update only the REMOTE indicator?
You can get anything if there are logical errors in the code.
Actually OnTick is not synchronised with OnCalculate by the same symbol. Theoretically, OnTick may be late and by its start all indications on all TFs will be calculated?
So far I see the opposite situation - indicators are not calculated with a new tick at the moment of bar opening.
The statement is a little ambiguous. Let me clarify it just in case. Yes, when processing a tick, all timeseries are processed in order, from the youngest to the oldest. Each tick is added to data of each timeseries, then indicators are calculated for each timeseries, in order. It means that for the indicator in OnCalculate(), the data of the time series (all timeseries) is certainly updated, but the data of the indicators of higher timeframes hasn't been recalculated yet.
What does it mean"calculation of indicators on each timeframe, in order" i.e. depending onthe "ENUM_TIMEFRAMESperiod"?
intiCustom(
stringsymbol,// symbol name
ENUM_TIMEFRAMESperiod,// period
string name// folder/user_name
...// list of indicator input parameters
);
And if there are two indicators with the same ENUM_TIMEFRAMESperiod and one is calculated from the data of another one, how to ensure the correctness of consecutive calculation?
Did I correctly understand that if the indicator is calculated(ENUM_TIMEFRAMESperiod) on M1, then when requesting the OHLC information it will receive the current information about the last tick for any upper TF?
iSpread ?
I see that it is roughly similar to the spread value if you query for bars in Symbols/Bars in the terminal.
Of course these values do not correspond to the real values given by SYMBOL_SPREAD.
Why such a difference? And what is such an unreal spread shown usingiSpread?
What do you mean by"calculation of indicators on each timeseries, in order" i.e. depending on"ENUM_TIMEFRAMESperiod"?
intiCustom(
stringsymbol,// symbol name
ENUM_TIMEFRAMESperiod,// period
string name// folder/user_name
...// list of indicator input parameters
);
And if there are two indicators with the same ENUM_TIMEFRAMESperiod, and one of them is calculated based on the data of another one, how to ensure the correctness of a consecutive calculation?
This is provided by the terminal.
Did I correctly understand that if the indicator is calculated(ENUM_TIMEFRAMESperiod) on M1, then when requesting the OHLC information it will receive the actual information about the latest tick for any upper TF in any case?
Yes, exactly so.