|
Post by jarychk on Jul 7, 2024 8:54:17 GMT
The JB Helpfile shows a sample piece of code, which I am trying to learn from and the use.
I have a file, created through a J B program which is THIS:
Then this block of code should, what, tell the number of bytes in the file? But it seems to simple put the file contents all in a horizontal line, so not sure what is "bytes" and not sure how "number of bytes" is "1171".
open "programoptions.txt" for input as #1 qtyBytes = lof(#1) for x = 1 to qtyBytes print input$(#1, 1) ; next x close #1
I hope to find if the file is either empty or if it has an expected count of values as its content; like if it has ANYTHING in it, it should have three values in it.
|
|
|
Post by jarychk on Jul 7, 2024 9:04:42 GMT
I already believe a practical way to handle is is possible.
I changed the file contents to be simply this:
and after the loop but before "close", inserted PRINT lof(#1) which outputs the number 9. Three single digit values in the file, and length of file is 9.
I do not fully understand but I may work with this. Main idea is, in case the file does not have enough in it, create a default file, with certain default values.
|
|
|
Post by tenochtitlanuk on Jul 7, 2024 13:26:55 GMT
![](https://www.diga.me.uk/fileStructure.gif) Welcome to the world of files! Files are simply a list of 8-bit numbers, each therefore between 0 and 255. Text files represent the printable characters, coded as numbers from 32 to 255. Numbers between 0 and 31 are 'control' codes that mean something to a printer or display or program. The control codes of most importance are CR ( carriage return) and LF (line feed). On the old mechanical teletypewriters they move the print head back to full left, and advance the paper one line. So that a data file can show separation of one item from another we need a 'separator' control code. This is typically a TAB, a comma, a CR, a LF, or a CR+LF. CR+LF is characters number 13 ( 0D in hex) and 10 ( 0A in hex). The image, created with a 'hex editor', shows that when you simply store your three numbers to a file, in order to know when one stops and the next number is intended, my computer has added CR+LF in between them. There are your extra bytes. Unfortunately, the worlds of Microsoft, Linux and Mac disagree on which is the 'standard' separator. Files created/read on your OWN computer will give no trouble. But those from the 'other' worlds need converting.
|
|
|
Post by Rod on Jul 7, 2024 15:35:31 GMT
When you print “1” to a file Liberty actually sends “1CrLF” three characters. As John explains the CrLf pair are control characters.
You can prevent this by print “1”; the ; stops Liberty adding the CrLf pair but then you have no line separator.
You can build the file in whatever format you wish but standard protocol adds CrLF and so three “1”s becomes 9 characters in the file.
|
|
|
Post by jarychk on Jul 7, 2024 17:08:04 GMT
Rod (and @tenochitlanuk) That lets the program creator make code to check for some quality of the file to be used. If such a file needs to contain three values, then each value giving three characters, or possibly four characters if the piece of the file is two digits. I'll have to check again more carefully. If the file contained the pieces 11, 7, and 1, then the length of the file should be 4+3+3=10; but when the computer program checks the quality of the particular file, and the file needs to contain three values, then the file is good if LOF greater or equal to 9; and bad if LOF less than 9. After checking the quality of the file, program can be coded to conduct proper actions.
|
|
|
Post by jarychk on Jul 7, 2024 17:12:19 GMT
just one small question: Which happens first when a new piece of data is put into a sequential file? The line feed or the carriage return? Is this important?
|
|
|
Post by plus on Jul 7, 2024 18:54:01 GMT
Chr$(13) is enter key AKA CR or carriage return
then Chr$(10) is line feed key.
Also sometimes a Basic will insert an extra CR + LF at the end of the file, so if you get 2 extra bytes than expected, it's probably that.
b = b + ...
|
|
|
Post by jarychk on Jul 7, 2024 19:58:52 GMT
(Quotes button is not present in your post; I will copy&paste part of...)
You did not say it distinctly but the answer might be guessed as, the carriage return happens first, and the line feed happens next.
Another thing I have trouble understanding is the exact meaning of "Carriage Return". When we use this for displaying text information, just using chr$(13) puts the continued display onto a fresh line starting at the left side. I cannot understand this to not be also Line Feed.
But no matter - I am making progress with an application in development currently.
|
|
|
Post by plus on Jul 7, 2024 21:10:55 GMT
Yes chr$(13) is first and chr$(10) is 2nd or they are used singlely usu chr$(10) more than chr$(13) depends on file and system you are working with. And they both will likely do the same thing singlely with PRINT statements. Carriage return and line feed are from old, old, old printers that were more like type writers. CR ends the line, ding! on the type writer LF is grabbing that lever and manually shifting it left, meanwhile a physical gear rotates the roller so you start the next line. They used these typewriter like devices for the first "Dummy Terminals" for main frame access INPUTs and OUTPUTs inputs you type something outputs the computer sends something back on the next line or so... some times pages and pages of stuff. And you had to worry about reloading paper that was used like TP ![:)](//storage.proboards.com/forum/images/smiley/smiley.png) b = b + ...
|
|
|
Post by Rod on Jul 8, 2024 6:33:53 GMT
Yep, in the old days, fifty years ago, control characters moved the print position, Cr slung the head back to the start of the paper, Lf moved the paper up a line.
Nowadays it is entirely up to the software system displaying the text how these characters are interpreted. Some systems don’t even use two characters anymore. Mostly all systems will now start at the left edge and down a line if they encounter one or both of these characters in a file.
Fortunately we most often create our own files so it is easy to pick one protocol and stick with it.
|
|
|
Post by tsh73 on Jul 8, 2024 10:01:23 GMT
Hello jarych I tnink if you need to make sure file contain three numbers you just go on and read these 3 numbers You can check if file is ended (EOF) in process, so you have some number missing And you can check range to see if number is valid (like, reading "abs" as number produces no error but returns 0, But if 0 is out of range, you know that something is wrong.) Play with this.
open "test.dat" for output as #1 print #1, 1 print #1, "abc" 'thing that reads as 0 'print #1, 2 'missing items it caught bu EOF(), no error happens 'print #1, 3 close #1
timer 300 , [nxt] wait
[nxt] timer 0
open "test.dat" for input as #2 k=0 while not(eof(#2)) and k<3 'fils in not ended, and we need only 3 numbers (extra will be ignored) k=k+1 input #2, a(k) wend close #2
print "Have read ";k; " numbers" print "only if you see 0 it could be something in a file that could not convert to number" for i = 1 to k print a(i) next
|
|
|
Post by plus on Jul 8, 2024 12:13:53 GMT
If LOF(#1) = 0 then Print "The file is empty" else ' load file endf if
b = b + ...
|
|