Here's the code surrounding the error point simplified to a test function, without the Easyptr stuff. This should clarify what is happening line by line so we can see which keyword exactly is causing the issue.
Q_ERR_ON temporarily converts a procedure like OPEN_IN into a function (internally) so that the Q_ERR function can pick up an error code instead of the program just stopping with an error like a procedure call normally would. If there is no error, Q_ERR returns 0. If there is an error, Q_ERR returns a negative value equivalent to the corresponding QDOS error codes. I've kept the line numbers the same as the original where possible.
Issues to suggest:
1. The Q_ERR_ON command is being used in a FuNction, in case this is relevant.
2. The program, compiled and uncompiled, is over 64K. The line which is causing the problem seems to be about 65% through the program code. Probably just coincidence and very unlikely, but as I'd noticed it, I thought I'd mention it in case 64K is relevant, in case there's a word/long word length issue.
3. The View_A_File function as it stands in this curt down example will return either a negative error code such as -7 for Not Found (accompanied by a "grunt" BEEP in line `18260), or 0 if the OPEN_IN succeeds.
By adding a "breakpoint" before each line you should be able to pick up which keyword is causing the issue. If this program works and doesn't show the problem, there will be two issues to consider next:
1. program length - e.g. does it only happen over 64K.
2. Easyptr has somehow caused an issue, in which case diagnosis may be more difficult
Code: Select all
100 src$ = 'win1_' : file_name$ = 'random_doc'
12920 file_in_list = View_A_File(src$&file_name$,1)
12922 :
18060 DEF FN View_A_File (called$,lr%)
18070 LOCal a,actions,stat%,t$,num2,fer
18240 Q_ERR_ON 'open_in'
18245 OPEN_IN #3,called$
18250 fer = Q_ERR
18255 Q_ERR_OFF 'open_in'
18260 IF fer < 0 THEN BEEP 5e3,50 : RETurn fer
19480 RETurn 0 : REM success
19490 END DEFine View_A_File