 Notice. New forum software under development. It's going to miss a few functions and look a bit ugly for a while, but I'm working on it full time now as the old forum was too unstable. Couple days, all good. If you notice any issues, please contact me. |
Forum Index : Microcontroller and PC projects : Syntax confusion for input #.
| Author | Message | ||||
| Paul_L Guru  Joined: 03/03/2016 Location: United StatesPosts: 769 |
Things that make you go HMMMMMMMMMM.... The manual says 1 Except for PRINT, INPUT and LINE INPUT the # in #fnbr is optional and may be omitted 2 LINE INPUT #fnbr, ...... 3 OPEN fnname$ FOR mode AS [#]fnbr 4 CLOSE [#]fnbr[, [#]fnbr] .... I'm trying to keep track of ten data files so I set up pointer constants and arrays. DIM fn$(10) length 12 = ("first.txt","second.txt",third.txt", ..... ) 'filenames DIM fz%(10) 'flag array fz%(n) will be set to 1 if the file is open, 0 if closed CONST pf1=1,pf2=2,pf3=3, ..... 'pointers to the arrays fn$() and fz%() I intended using the constants in commands like this. IF fz%(pf2)<1 then ' the file is closed, open it on error skip:OPEN fn$(pf2) for INPUT AS pf2 if MM.Errno then fz%(pf2)=0 else fz%(pf2)=1 ' if it opened then set the flag endif if fz%(pf2)>0 then LINE INPUT #pf2, x$ 'if its open read it if fz%(pf2)>0 then CLOSE pf2:fz%(pf2)=0 'if its open close it It seems to me that the program line "LINE INPUT #2,X$" is read by the interpreter as individual characters, not numeric values. If the constant pf2 is inserted into the code as a character literal during program load will it be interpreted properly as "fnbr"? Is the constant inserted into the code as a string or a numeric? If the constant is inserted as a literal character string is it necessary to evaluate the string like this? OPEN fn$(EVAL(pf2)) for INPUT AS EVAL(pf2) LINE INPUT #EVAL(pf2), x$ CLOSE EVAL(pf2) ' evaluate the chars substituted for pf2 Paul in NY |
||||
Geoffg Guru Joined: 06/06/2011 Location: AustraliaPosts: 3308 |
The file number can be a numeric constant or expression. The logic that the interpreter uses is simple: // is the first argument a file number specifier? If so, get it if(*argv[0] == '#' && *argv[1] == ',') { argv[0]++; fnbr = getinteger(argv[0]); } It first checks that the first argument starts with a hash and that it is followed by a comma. If this is true it means that a file number has been specified. If so, it steps over the hash character and interprets the rest of the argument as a number. This number can be a constant (ie, 3), a variable, an expression, CONST, etc. For example, this works as expected: fnbr = 4 Open "RTEST.BAS" For Input As #fnbr Line Input #fnbr, X$ Print X$ Close #fnbr So, your line: if fz%(pf2)>0 then LINE INPUT #pf2, x$ 'if its open read it should work perfectly. Geoff Graham - http://geoffg.net |
||||
| Paul_L Guru Joined: 03/03/2016 Location: United StatesPosts: 769 |
Hi Geoffg, Your technique of using argv[n] as a pointer to the position in the argument string and then incrementing the pointer with arg[0]++ is elegant! Now I see why MMBasic is so robust. It's nice to know that I am not wandering around in an antiquarian wilderness. I'm trying to write data driven code which depends heavily on incrementing pointers into big array structures and using the data stored there to determine program flow. So far I've been able to do it without using the EVAL() function. Thank goodness I don't have to write it on Hollerith cards! Thanks for looking at the snippets. Paul in NY |
||||
 Print this page |
 |
The Back Shed's forum code is written, and hosted, in Australia. | © JAQ Software 2025 |
