Read a text and attribute it to a variable

[krovit]

Code: (Select All)

x=freefile

open "c:\test.bas" for input as #x

line input #x, j$

close

? j$

Good morning or good evening or even good afternoon...

The answer to my question will certainly be simple 'Cause I'm slipping away Something obvious, but at the moment I can't figure out where the error is. Sometimes I get lost in a glass of water...

How can I turn j$ - into a string such that it can give me the result of p$ ?

Thank you!

Code: (Select All)

p$ = "QB64 Phoenix "+CHR$(138)+" (is) beatiful"

? p$

[mnrvovrfc]

Does the TEST.BAS exist on the root directory of the C: drive?

Because that's what your program is asking for.

Also check for file existence like this:

Code: (Select All)

myfile$ = "test.bas"
if _fileexists(myfile$) then
'do something with myfile$
else
print "Sorry but "; myfile$; " was not found."
end if

Do not use CLOSE by itself. If you have more than one open file, CLOSE on its own will close all the files which is probably what you don't want. This could consume many minutes in debugging.

Do not hard-code paths to files. If you share the program with somebody who does not use Windows, they will be unable to use the program and will be unwilling to fix it. Especially if they're told to install Wine and use the Windows version of QB64...

[krovit]

Do not hard-code paths to files. If you share the program with somebody who does not use Windows, they will be unable to use the program and will be unwilling to fix it. Especially if they're told to install Wine and use the Windows version of QB64...

Yes, it's true, some people also use Mac or Linux, I hadn't thought about it. I apologize.

It seems to me that the problem that I can't solve is clear anyway and the test.bas file can be anywhere.

The problem is that I can't attribute what is read to a variable. In practice, the text, as you can see with the CHR$ statement, is not interpreted.

[mnrvovrfc]

Does your TEST.BAS have a blank line as the first line of the source code? Like it is shown here on the forum?

Also you're getting only one line. How about working something like this:

Code: (Select All)

DIM x AS LONG

x = FREEFILE

OPEN "test.bas" FOR INPUT AS #x

DO UNTIL EOF(x)

    LINE INPUT #x, j$

    IF j$ <> "" THEN EXIT DO

LOOP

CLOSE

PRINT j$; "|"

[RhoSigma]

I guees he doesn't have problems reading the text from the file, but he's wondering why it prints as it is in the file. Seems to me as he'd expect the CHR$(138) should magically turn into the respective char as it happens when he directly assignes it to a variable, but that's not possible. The text is read as is from the file into the variable, it does not evaluate the code the text contains. That would require to pass it through an EVAL() function as it exists in some laguages (eg. JavaScript) but not in QB64.

How can I turn j$ - into a string such that it can give me the result of p$ ?

Sorry, not possible in QB64 as is.

It would require to evaluate the BASIC code (CHR$), but for the LINE INPUT function this is just text, no code.

[krovit]

Wait, I'll try to explain!

The code I had proposed was kept to a minimum, just to make the problem clear without giving too much weight to the code itself.

The TEST.BAS file is a simple text file (perhaps better called TST.TXT) and contains only one line.
Including the quotation marks, the line is as follows:
"QB64 Phoenix "+CHR$(138)+" (is) beatiful"

The code that opens and reads the file loads the entire line and puts it in the j$ variable.
The problem - but maybe it's me who doesn't see something obvious - is that the compiler (or I don't know what else) doesn't recognize the instructions.

In fact, if you were to write and compile this line of code:
j$= "QB64 Phoenix "+CHR$(138)+" (is) beatiful"

I get:
QB64 Phoenix è (is) beatiful

Instead, reading the line from the file and assigning it to j$ - running the compiled code - I just only get:
"QB64 Phoenix "+CHR$(138)+" (is) beatiful"

[krovit]

I've only just seen RgoSigma's answer... (

I'll have to invent something to solve my problem (it will take a lot of imagination)

[mnrvovrfc]

... could use RUN on the BASIC source code? That's in addition to the code that loads that same source code as a text file.

The problem is that if there is no EXE file on Windows for TEST.BAS it will be created by the QB64 compiler and it will take many seconds. If the EXE already exists then it's just run. However, it might not have come from the source code you thought was in TEST.BAS! This is easy to investigate: without compiling TEST.BAS, just find any other EXE file, copy it to QB64 directory and rename it TEST.EXE. The RUN statement will happily run that without checking to see if the BASIC source code was compiled to get that EXE file.

You could add a sanity check: first load the BASIC source code as text file. Then make sure is the right one by searching a string loaded from the file, such as + CHR$(138) + . If there is a match then you ask to RUN that source code.

But maybe I shouldn't be proposing to use RUN...

Otherwise you will need a BASIC interpreter as part of your QB64 program. Load the BASIC source code as text file, then have the interpreter work with it for the result you originally expected.

[SMcNeill]

Can you not just write the text file with the formatting already done?

OPEN "Test.txt" FOR OUTPUT AS #1
PRINT #1, " QB64 Phoenix è (is) beatiful"
CLOSE #1

[mnrvovrfc]

Can you not just write the text file with the formatting already done?

OPEN "Test.txt" FOR OUTPUT AS #1
PRINT #1, " QB64 Phoenix è (is) beatiful"
CLOSE #1

The topic starter wants to execute BASIC code that is loaded from a text file (another BASIC source code). Which is not possible, I guess unless the "host" BASIC program contains a BASIC interpreter.

It was expected to load the TEST.BAS and execute the PRINT statement together with the CHR$() call, to produce the accented "e". That's why I was (poorly) suggesting to check for such a line while loading that text file, to make sure it's genuine before using RUN to execute the BASIC code that is being loaded as text file. Confusing, yes I know...