Dimitris: Oooh! That works! Weird. I'll have to write a little code to parse out my data from the single string variable, but that's a great work-around if I can't get EOF to work.
Thanks! Ed K. Dimitris Anogiatis wrote: > Ed, > if reading a text file and extracting information from it is what you're > trying to do, why not just use > > tmp = File.Load(Fname) > > File.Load is documented over here > http://www.gambasdoc.org/help/comp/gb/file/load > > after loading the contents of Fname in tmp you can do your magic, without > using an OPEN statement and a loop > unless the file you're reading is a few megabytes, File.Load should be > sufficiently fast to cover your needs. > > I am sure that there's more than one ways to skin a cat, and professionals > didn't exactly drop out of the sky one day > knowing everything about programming :) It takes practice and more practice > and even more practice :) we all learn > in different ways and we're all here to help each other :) Whether we are > professionals,amateurs hobbyists or plain curious > > As they say in my country, One hand washes the other and both wash the face > :) > > Hope this helps > Regards, > Dimitris > > On Mon, Apr 19, 2010 at 1:17 AM, Ed & Clare Kelm > <twopil...@interisland.net>wrote: > > >> Hi all: >> >> A couple of comments about the discussions below: >> >> 1. The test program was written with EOF at the start, because the >> actual program I am working on has this structure, for reading in >> multiple lines of text: >> >> WHILE NOT EOF(tfile) >> (bunch of code for reading the lines in and putting the data in the >> proper places) >> WEND >> >> CLOSE #tfile >> >> When that failed, I wrote the test program to see if I was actually >> sometimes getting an EOF immediately after opening the file, since the >> first thing WHILE does is test EOF. >> >> 2. Clearing label1 after every button click is just a little >> insurance. Given that things weren't working as expected, I wanted to >> make sure what I saw in label1 was new info, not something left from the >> previous button click. I know that shouldn't be necessary, because the >> IF-THEN-ELSE structure will always write to the label - but then there >> shouldn't be an immediate EOF either. >> >> 3. Using Fname like that is just a little habit I've developed. It >> allows me to try a different file by commenting out one setting of Fname >> and writing a new one, without erasing the previous one. And it makes >> the OPEN statement more compact and easy to read. It is also sometimes >> useful to put such equates all in one place, so it's easy to find and >> change parameters, rather than rummaging around in the code. You are >> correct, it is sort of a waste if I am only using the variable once. In >> my actual program, Fname also gets used when the database gets modified >> and the file then has to be re-written. >> >> I am not a professional programmer, so I'm sure I have some ways of >> doing things that make professionals cringe! >> >> Thanks again for thinking about my problem! >> >> Regards, >> >> Ed K. >> >> Doriano Blengino wrote: >> >>> Les Hardy ha scritto: >>> >>> >>>> Doriano Blengino wrote: >>>> >>>> >>>> >>>>> Les Hardy ha scritto: >>>>> >>>>> >>>>> >>>>> >>>>>> Hi Ed, >>>>>> I figured it out. >>>>>> First of all, depending how the text file was emptied/created, the >>>>>> contents may not be truely empty. >>>>>> Gedit for example leaves the 0A (end-of-line) character in the 'empty' >>>>>> file. This is recognised by eof() as a character, so, end-of-file is >>>>>> >> not >> >>>>>> found. >>>>>> I am not sure if this can be considered a bug in Gambas, but it does >>>>>> mean an eof() is only good for preventing read errors, and is not >>>>>> reliable for testing if a file is empty. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>> Just breaking in to say that a file with a EOL in it is not an empty >>>>> file - it is a file with an empty line in it... >>>>> >>>>> >>>>> >>>>> >>>> Your correct, I agree completely, but the original code Ed supplied, ' >>>> IF Eof(tfile) ' cannot work , as it checks eof before a read. >>>> When I saw he was using eof() that way, and knowing empty files are not >>>> always empty, I thought I had found his problem, so I just added a bit >>>> of code that should have got around it. >>>> >>>> I am sure you will agree, that, whatever other problems he may have, he >>>> needs not to use eof() the way he is. >>>> >>>> >>>> >>> Here is the original code. I think it is perfectly right: >>> >>> >>>> PUBLIC SUB Button1_Click() >>>> >>>> DIM tfile AS File >>>> DIM Fname AS String >>>> >>>> Fname = "/home/us/Documents/testdat.txt" >>>> >>>> tfile = OPEN Fname FOR READ >>>> >>>> label1.Text = "" >>>> >>>> IF Eof(tfile) THEN >>>> label1.Text = "EOF" >>>> ELSE >>>> LINE INPUT #tfile, label1.Text >>>> END IF >>>> >>>> CLOSE #tfile >>>> >>>> END >>>> >>>> >>>> >>>> >>> If eof() is not checked *before* reading, then when? I see only two >>> things I would not do (but it depends a lot). First, why use the "fname" >>> variable, if it is used only once... second, why set label1.text if that >>> .text will be anyway written shortly later? >>> >>> But, apart from these two very little things, that can also have some >>> good reason, the rest of the code is the only possible, I think. Note >>> also that label1.text can get 3 different values: "EOF" is the file is >>> empty; "" if the first line of the file is empty; something else if the >>> first line of the file contains some data. These three cases cover all >>> the cases we talked about (empty and not empty files), and I think our >>> friends know what they are doing. >>> >>> Of course I may be wrong, but that use of eof() seems to me fully ok. >>> >>> Regards, >>> >>> >>> >> ------------------------------------------------------------------------------ >> Download Intel® Parallel Studio Eval >> Try the new software tools for yourself. Speed compiling, find bugs >> proactively, and fine-tune applications for parallel performance. >> See why Intel Parallel Studio got high marks during beta. >> http://p.sf.net/sfu/intel-sw-dev >> _______________________________________________ >> Gambas-user mailing list >> Gambas-user@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/gambas-user >> >> > ------------------------------------------------------------------------------ > Download Intel® Parallel Studio Eval > Try the new software tools for yourself. Speed compiling, find bugs > proactively, and fine-tune applications for parallel performance. > See why Intel Parallel Studio got high marks during beta. > http://p.sf.net/sfu/intel-sw-dev > _______________________________________________ > Gambas-user mailing list > Gambas-user@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/gambas-user > > ------------------------------------------------------------------------------ Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev _______________________________________________ Gambas-user mailing list Gambas-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/gambas-user