I have been researching this topic and also tried creating the indicator with parameters but I still get this error when calling the value from the indicator into my code. Now I know the code of the indicator could have been done in the Builder itself but this is just the beginning and I wanted to keep it simple so we can get to the bottom of the problem.
Error: Backtest cant start because of a parsing error in the code : line 1, column 0.
Here is the Pro Builder code.
Tradeok = Call "TurnofMonth"[22,4]
// Conditions to enter long positions
IF NOT LongOnMarket AND Tradeok THEN
BUY 1 CONTRACTS AT MARKET
ENDIF
// Conditions to exit long positions
If LongOnMarket AND Not Tradeok THEN
SELL AT MARKET
ENDIF
Here is the indicator code
Timeframe(Daily)
IF Openmonth<>openmonth[1] Then
Dayofmonth =1
else
Dayofmonth= Dayofmonth+1
endif
Tradeok=1
If Dayofmonth > End and Dayofmonth<Start Then
Tradeok = Tradeok-1
else
Tradeok = Tradeok
endif
Return Tradeok as "Tradeok"
Thank you
JSParticipant
Senior
Hi,
Adjust the following in your indicator:
Remove: Timeframe(Daily)
Verander “If Dayofmonth>End OR Dayofmonth<Start then
How dumb of me, thank you.
Just a follow up question why do the Timeframe(Daily) code line also cause an error?
Just a follow up question why do the Timeframe(Daily) code line also cause an error?
So from further testing it looks like the Timeframe command is only to be used in ProBuilder not in ProBackTest or the Indicator module. Please confirm.
the Timeframe instruction can be used in any editor (backtest, indicator or screener).
I think you have a problem somewhere else in your code or maybe there is a typo?
I’m having the same issue , parsing error when I try to call an indicator with different timeframes.
Has anyone figured out a solution for this?
it’s not the other way round
If Dayofmonth > End and Dayofmonth<Start Then
If Dayofmonth < End and Dayofmonth>Start Then
I can’t comment for screeners because I don’t use. For indicators this doesn’t seem to be a problem. With back-test and beyond it is.
I don’t know the exact reasons why, but the ‘Parsing Error’ comes up when ‘Timeframe()’ is placed in a ‘Call’ed file.
In example above, ‘ Timeframe(Daily)’ is in the called file. This triggers the parsing error.
Though above solution by
@JS removed the need for ‘Timeframe(Daily)’ it indirectly removed the condition triggering the ‘parsing error’.
To use the ‘Timeframe’ instruction and ‘CALL’ files, when this happens, is to put ‘Timeframe()’ in the Main file and call the other file(s) from within the timeframe block.
The other file(s) will be generic and not use ‘Timeframe’.
This is just to avoid this error with back-test, however if you skip back-test and create an Auto trading file, it fails to run because of an ‘internal error’.
When you look at the Auto code, the call files code is represented as a function, and after the main code. Maybe this points to a possible reason why it works one way but not the other. I’m assuming the same process happens when back-test is done. The lack of additional processing of the code values with BT and AT may be the reason why it works with indicators.
JSParticipant
Senior
Maybe as a supplement….
Of course, parsing errors can arise from different situations, but what I’ve seen in PRT is usually a combination of arrays with certain instructions, for example when you use the “Crosses Over” or “Crosses Under” instruction in combination with values from an array, a “parsing error” follows because the array is not related to the time frame in which these statements are used… (the times cannot be linked)…
One solution could be to use “normal” variables instead of arrays… (if possible)
Because arrays are not related to a time frame, statements such as, $myArray[n][1] also return a parsing error…
As has been pointed out several times on the forum, a “Call” instruction, in combination with an indicator that uses MTF, also results in a passing error…
The current solution is to incorporate the indicator into the system from which the “Call” takes place…
When everything has been tried but has failed, the last option is to send a technical report and have your code checked for, syntax errors, unexpected symbols, incorrectly nested structures, wrong data format, etc.
Ok thank you, I’ll just copy the code to the main program then.
