Normally your code will be executed again with each new “tick”, but when you use “UpdateOnClose” your code will only be executed again at the end of the bar (Close). So with TimeFrame(10 minutes, UpdateOnClose), the code, under that time frame, runs at the end of every 10 minutes.
It could be more than a good idea to have a clear definition of the MTF feature at the end of this topic, as I haven’t seen one yet. I am not even sure I could make one as f now, while I am using MTF all over the place.
For me the answer to this – or a good example would enlightening :
TF of the chart is 1 minute
TimeFrame(5 minutes, UpdateOnClose)
[my code 1]
TimeFrame 5 minutes, Default) // This will make the TF 1 minute (equal to the chart’s TF).
[my code 2]
As far as my experience goes, the 5 minutes, default makes no sense and behaves the same as
TimeFrame (default)
or if you want (for more clarity in your code)
TimeFrame(1 minute, Default)
So does someone have a good example of my code 2 which justifies the TimeFrame(5 minutes, Default) command ?
“Justifies” means : it can not be replaced with TimeFrame(Default) or TimeFrame(1 minute, Default) in that example.
A small hint for the hopefully clear description : Nicolas tends to explain this by means of the phenomenon “Strategy” where the strategy as such would be coded under the higher TimeFrame – the ordering system can independently of that execute under the lower (faster) TimeFrame. But I don’t see how a Strategy would be an EMA and such of a TimeFrame. To me the Strategy is the complete system (the whole code and all its interactions with averages and orders and all). This makes the explanations from Nicolas tedious to grasp for me.
Another good thing to endorse would be that we restrict ourselves to Strategy Code (which is the main code vs Indicator code) because from the perspective of the Indicator, stuff like Ticks do exist – within a TF visually, though it is not related to MTF. No such thing as a lower level in Ticks combined with a higher level in Time in Strategy Code exists (as far as I am aware).
Regarding this, all explanations I read immediately confuse bars with bars (ahem) while we, the user, only see one set bars of one TF at the time (no smart drawing assumed via an indicator). So my example above would show one set of bars only : that of the 1 minute TF. All other “TF Bars” we may refer to, are virtual. So we have a 5 minute TF in place in parallel, but the bars of that we can not see. Now, it is not convenient to refer to both TF situations as “at the close of the bar” because I get dizzy of such expressions which tell exactly nothing. Hence :
We should be clear in our expressions and they should be uniform. The Close of a bar exists and it should be the one we can see visually. It is always the bar of the TF of the chart. Sadly, if we have a reference in the code to e.g. Close[2] and it is under the scope of the 5 minute TimeFrame, it means 2 bars back in that TimeFrame. So sure, those bars virtually exist just the same (in parallel).
Nicolas refers to this as the Superior (in my example 5 minute) and Inferior (in my example 1 minute) TF. I think this is good.
So this all did not answer a bit of what MaoRai54 was asking. But it should give some context on what UpdateOnClose means. This should be simple : this refers to the close of the (virtual) bar of the TimeFrame defined in the same command. Thus, whether the Superior TF is NOT (!!) allowed to see the status of all at the close of the bar of the TF of the chart. Remember the Default option hence the TimeFrame definition for my code 2 I see no justification for, which DOES allow to be updated with all at the close of the bar of the TF of the chart.
May it help (or debunk my thinking) : I banned all the “default” from my codes. And to hopefully grab better what this in the end is all about – apart from calculating indicators (averages and such), here what I coincidentally added to a code yesterday :
1
2
3
4
5
// 06-08-2022,PS, Here, at the very end of the code, we determine whether we want to exit regarding a set amount.
// we do this at the end, so we can catch for the smallest TimeFrame (the one of the chart) possible, so it will
// never interfere with any other time frames and not allowed If commands etc.
TimeFrame(10Second,UpdateOnClose)
Notice the chart *is* at 10 seconds.
I show this because the UpdateOnClose there could be replaced with (10 second, Default) or (Default) with no changing behaviour. But if I then change the TF of the chart, I’d go mad at adjusting the code, because this part should never adapt automatically (it would change the outcome of orders all over). This is personal and for me good habit. I merely show it so things possibly start to make sense.
Again, at the end of this topic I’d hope that a nice unambiguous description has emerged. It is all not difficult at all, but it is a challenge to write it out in a way everybody understands. In a compact sentence or two, hopefully.
timeframe(default) refers to the timeframe on your chart (the DEFAULT one), whatever it is (it must be the smallest TF used); it’s the TF that sets the pace at which the code is executed. If you write timeframe(default) you can use any TF of your choice (provided you abide by the rule of multiples as stated below), while if you write timeframe(1m) or timeframe(1m,default), then your chart MUST use a 1-minute TF.
Addintional TFs, such timeframe(10m,default) or timeframe(10m) is any other TF allowed by the MTF support and each one of them must be a multiple of the default TF. The optional keyword DEFAULT means that all variables are updated according to the pace set by the default TF (i.e. when the default candle closes), using the optional keyword UpdateOnClose (or replacing default with UpdateOnClose) makes all variables be updated when the named candle (in this case a 10-minute candle) closes, instead.
A maximum of 6 TFs are allowed (default one included). timeframe(10m,default) and timeframe(10m,UpdateOnClose), if both are used, are considered as ONE timeframe (despite they have two different behaviours).
.
