...before posting any answer I would like to understand, what do you consider a multi-time frame strategy in custom indicator context.
How to make the step forward?
Select your own way - The Approach
In any case,
one can use function calls aimed to retrieve values, collected from a perspective of a different time-frame, with a use of proper indication of
{ PERIOD_M1 | .. | PERIOD_H1 | PERIOD_H4 | .. }
in the function call protocol,
or
one can create and maintain one's own virtual super-framing / sub-framing independently of the current graph's "own" time-frame.
double v30SEC_O[], v30SEC_H[], v30SEC_L[], v30SEC_C[],
vM1_O[ ], vM1_H[ ], vM1_L[ ], vM1_C[ ],
vM3_O[ ], vM3_H[ ], vM3_L[ ], vM3_C[ ],
vH7_O[ ], vH7_H[ ], vH7_L[ ], vH7_C[ ]; // vTF as needed
bool v30SEC_newBarEVENT = False,
vM1_newBarEVENT = False,
vM3_newBarEVENT = False,
vH7_newBarEVENT = False;
void aNewBarEventMONITOR(){ ...
static int v30SEC_Bars = EMPTY,
vM1_Bars = EMPTY,
vM3_Bars = EMPTY,
vH7_Bars = EMPTY;
// check aNewBarEVENT:
// update state-vars:
}
Does it work in spite of many posts on failed MTF [StrategyTester
] results?
In each of cases posted above, one may use the other one to check and proof the correctness of the outputs.
Yes, unit-tests are a good safety belts habit in this domain.
The recent "new"-MQL4.56789+
shifts and frequent interim compiler ( syntax ) live-updates ( you get a new Help to notice them ) make unit-testing a must-do part of the pre-release testing + production code maintenance.