Page has been tested for compliance with INDUSTRY (not MS-only) standards, using the free, publicly accessible validator at validator.w3.org. Mostly passes.Text files can be remarkably useful. The page you are reading is "just a text file", for instance!
Reading a text file can be easy or difficult, depending on your operating system. This essay was inspired by a wish to read lines of text from an SD card into an Arduino. (They would tell the Arduino the SSID and password of the local WiFi, so the Arduino could connect to the WiFi.)
The Arduino gives you a way to read individual bytes from a file.
First you have to check that the file is there, opening it, etc. Then, to send the bytes in the file to the serial monitor, it's just a matter of...
while (myFile.available()) {
Serial.write(myFile.read());
}//end of "while.."
Wouldn't it be nice, though, if you could do something like...
while (myFile.available()) {
sTmp=sFetchLineFromFile(myFile);
//Do something with sTmp here
}//end of "while.."
Something like sFetchLineFromFile is not a built in function.
Probably because what a user might want "a string" to mean is so complex!
I don't, yet, have an answer my want... but I've pinned down what it is a little bit in this essay.
I hope that will help you if you want the same thing. If anyone gets the function written, I would be delighted if they offered it, or a link to it, for posting here! (All rights waived, of course. And no, Virginia, I wouldn't pay for it. Sorry. Will you pay me for the problem definition?
For students of programming, I hope this essay will be a useful example of the sort of "problem definition" that should precede coding activities!
"A file" will consist of...
Lots of bytes! If the file consisted ONLY of what a human would think of as ABC, then the bytes, in decimal, would be 65, 66, 67.
A "text file" is usually mostly only bytes that computers turn into characters on a screen. 66 for "A", etc. (That's about 80 characters in all... a...z, A...Z, 0..9... plus things like "+", "%" and so on. The space "character" is just as much a "printable" character as, say, "A", by the way.)
Lots of number you can show with a byte do NOT appear in text files. A byte can be anything from 0 to 255. Don't try to look at a jpeg in a TEXT editor!
But text files almost always at least have some bytes standing for "non-printable" things to signify the ends of lines. These bytes are 10 and/or 13. (Again, that's the number in decimal. You will often see them shown as 0A and 0D, which is the hex equivalent.) Different text editors use 10 and 13 in different ways.
You can't be sure that the file is what it should be. It may contain bytes other than...
As far as the "fetch line" procedure is concerned, only the 10s and 13s are "special". The string it returns may contain unprintable characters. This may or may not matter to you, but don't "mess with" sFetchLineFromFile to "fix" it. You can add a "sStripNonPrintables" function to your library, to call on the result of sFetchLineFromFile. Be careful, though... do you want to lose TABs, for instance? (Issues for another time! Let's "divide and conquer"... getting "the lines", as defined here, out of the file is enough to be going on with!)
Now we'll refine our definition of a text file further. First we need two terms. In the following...
The routine exists so you can extract the BoOCs one at a time from a file consisting of any of the following. (And it should respond graciously if there is no BoOCs in the file.)
Calling program must determine, separately, and handle, the eventual exhaustion of the file. Which (I think... must be tested!..) it will do, if used in the structure shown for dealing with the first case...
A file containing nothing!
(Function should not be called. The file should have been detected as empty by the external calling process.) This code....
while (myFile.available()) {
sTmp=sFetchLineFromFile(myFile);
//Do something with sTmp here
}//end of "while.."
... achieves that, i think. But that assumption needs to be tested. If all is well, it would be wise to put....
if (!myFile.available()) {
Serial.println("File was present, but empty.");
}//end of "if.."
.... in front of the other code.
A file containing just a BoLESs
(Function should return an empty string
Again, some warning to the user that, in effect the file was "empty" (empty of anything useful) should be passed to user.)
boFoundSomething=false;
while (myFile.available()) {
sTmp=sFetchLineFromFile(myFile);
if (sTmp!=''){boFoundSomething=true;};
//Do something with sTmp here
}//end of "while.."
if (!boFoundSomething)
{Serial.println("File was present, but contained only CRs and LFs";};
...maybe. Could that be less elegant?
Following cases should return a BoOCs in the string...
A file containing just a BoOCs
Remaining cases... files consisting of..
a) One or more (BoOCs followed by BoLESs). File ends at last BoLESs.
b) A BoLESs, followed by case "a" structure.
c) One or more (BoOCs followed by BoLESs), followed by one last BoOCs, but with no final BoLESs
So! That's what needs writing. I'll try to do it someday, if necessary... but I hope someone does it for me, for us... AND tests it, for all of the possible text file cases!
If you visit 1&1's site from here, it helps me. They host my website, and I wouldn't put this link up for them if I wasn't happy with their service.
Click here to visit editor's Sheepdog Software freeware, shareware pages.. Material on this page © TK Boyd 3/19
Click here to visit the homepage of my biggest site.
Click here to visit the homepage of Sheepdogsoftware.co.uk. Apologies if the "?FrmAht" I added to that link causes your browser problems. Please let me know, if so?
Page has been tested for compliance with INDUSTRY (not MS-only) standards, using the free, publicly accessible validator at validator.w3.org. Mostly passes.
AND passes...
....... P a g e . . . E n d s .....