I did search MQL5 forum but seems like iCustom is executed at incorrect sequence in OnCalculate when using it in different timeframe as the chart's base timeframe. below table in the left is when using same timeframe M5 for the chart and iCustom. right table is when using M1 timeframe in chart and using M5 timeframe in iCustom. Output behaviour of BarsCalculated and CopyBuffer function are quite different when iCustom is used in different timeframe. the difference can be found in the cells highlighted in red.
seems like this is current feature (bug) in these functions so wanted to learn ideals or what others have done to align the output to correctly.
issues
- instead of getting -1 at initial load, to obtain full calculated amount.
- calculated indicator values only return after a tick of new bar
If it takes X microseconds to access 100,000 bars of data, it'll probably take between X and 2X microseconds to access 2 x 100,000 bars of data. So having to wait slightly longer when you're also accessing data from MTF should be expected.
You can make your OnCalculate() do nothing and return 0 when BarsCalculate(g_ZZ_iHandler) is less than the bar count.
If it takes X microseconds to access 100,000 bars of data, it'll probably take between X and 2X microseconds to access 2 x 100,000 bars of data. So having to wait slightly longer when you're also accessing data from MTF should be expected.
You can make your OnCalculate() do nothing and return 0 when BarsCalculate(g_ZZ_iHandler) is less than the bar count.
appreciated for a fast feedback : )
i removed it from sample code but i actually did make it sleep for 50 and for loop for 10 times but it was same result so i removed it. are you saying you have tried my sample code with slep and was able to successful not getting -1 or slip sequence? if so, how long did you got it sleep?
appreciated for a fast feedback : )
i removed it from sample code but i actually did make it sleep for 50 and for loop for 10 times but it was same result so i removed it. are you saying you have tried my sample code with slep and was able to successful not getting -1 or slip sequence? if so, how long did you got it sleep?
Don't use sleep because it has no effect on indicators. And don't use loop, because it'll still be hogging the thread (and not giving the system any chance to complete calculation for the indicators you need).
You just have to return(0) instead of return(BTF_iBarCur), to indicate that no computation was done this time round, and do everything in the next tick - afterall the next tick probably comes before your're done with your long loop (or sleep, assuming that works)...
i have already tested it works on next tick but that is not what I need.
if you check my excel table.
left side of the table show when base chart timeframe (M5) and indicator timeframe (M5) are same, therefore there are no slipping.
right side of the table show when base chart timeframe (M1) and indicator timeframe (M5) are different, therefore there are slipping on the result of the calculated indicator values. (in pink cells)
is there a way not to get -1 at initial tick load and also slipping?
slipping means indicator returns update values on next tick of new bar.
i have already tested it works on next tick but that is not what I need.
if you check my excel table.
left side of the table show when base chart timeframe (M5) and indicator timeframe (M5) are same, therefore there are no slipping.
right side of the table show when base chart timeframe (M1) and indicator timeframe (M5) are different, therefore there are slipping on the result of the calculated indicator values. (in pink cells)
is there a way not to get -1 at initial tick load and also slipping?
slipping means indicator returns update values on next tick of new bar.
There is no slippage - check the times, not bar counts.
is there a way not to get -1 at initial tick load and also slipping?
slipping means indicator returns update values on next tick of new bar.
Of course you have a "slipping", the ZZ indicator and your indicator are calculated in the same thread, so they are calculated in sequence one after other.
Your indicator is calculated first, ZZ after, so you always have 1 ticks shift. That's why you have BarsCalculated(), to check what will have as values. You can use it and just wait the next tick to get new bar value of ZZ. This log shows situation on a new MTF (M5) bar :
2019.06.17 23:37:23.916 315917 (EURUSD,M1) tick#1 M5 Bars = 1000008 => 1000008 BarsCalculated = -1 => -1
2019.06.17 23:37:31.461 315917 (EURUSD,M1) tick#2 M5 Bars = 1000008 => 1000008 BarsCalculated = 1000008 => 1000008
2019.06.17 23:40:00.372 315917 (EURUSD,M1) tick#30 M5 Bars = 1000009 => 1000009 BarsCalculated = 1000008 => 1000008
2019.06.17 23:40:49.535 315917 (EURUSD,M1) tick#31 M5 Bars = 1000009 => 1000009 BarsCalculated = 1000009 => 1000009
2019.06.17 23:45:00.882 315917 (EURUSD,M1) tick#116 M5 Bars = 1000010 => 1000010 BarsCalculated = 1000009 => 1000009
2019.06.17 23:45:01.922 315917 (EURUSD,M1) tick#117 M5 Bars = 1000010 => 1000010 BarsCalculated = 1000010 => 1000010
If this "tick" shift is not tolerable for you (I am curious to know why in this case ?), you have two choices :
- Make sure ZZ is calculated before your indicator : I am not sure this is possible.
- Calculate all in one indicator, so you will have total control.
P.S: I am suggesting you, you post code on the forum and request for help, to not change standard variable names like OnCalculate rates_total, prev_calculated, etc... It's very annoying.
P.S²: Copying all history rates or indicator's buffer on each tick is a bit insane.
Hi Alan
Thank you for your feedback.
Of course you have a "slipping", the ZZ indicator and your indicator are calculated in the same thread, so they are calculated in sequence one after other.
Your indicator is calculated first, ZZ after, so you always have 1 ticks shift. That's why you have BarsCalculated(), to check what will have as values. You can use it and just wait the next tick to get new bar value of ZZ. This log shows situation on a new MTF (M5) bar.
If this "tick" shift is not tolerable for you (I am curious to know why in this case ?), you have two choices :
- Make sure ZZ is calculated before your indicator : I am not sure this is possible.
- Calculate all in one indicator, so you will have total control.
I agree your insight as I also read other comment and assumed it may be the case. It was good to confirm from expert's view.
I actually did #2 suggestion before I used iCustom but found out it will be easier by using iCustom but come across this issue and wanted to confirm my understanding was correct.
P.S: I am suggesting you, you post code on the forum and request for help, to not change standard variable names like OnCalculate rates_total, prev_calculated, etc... It's very annoying.
Noted, from next time I will make sure to keep it as standard naming. Apology and thank you for taking time to read my code.
P.S²: Copying all history rates or indicator's buffer on each tick is a bit insane.
thank you for your comment. I am not intend to call it every tick as it was for testing purpose.
- Free trading apps
- Over 8,000 signals for copying
- Economic news for exploring financial markets
You agree to website policy and terms of use
I did search MQL5 forum but seems like iCustom is executed at incorrect sequence in OnCalculate when using it in different timeframe as the chart's base timeframe. below table in the left is when using same timeframe M5 for the chart and iCustom. right table is when using M1 timeframe in chart and using M5 timeframe in iCustom. Output behaviour of BarsCalculated and CopyBuffer function are quite different when iCustom is used in different timeframe. the difference can be found in the cells highlighted in red.
seems like this is current feature (bug) in these functions so wanted to learn ideals or what others have done to align the output to correctly.
issues