[Gambas-user] EOF problem

Ed & Clare Kelm twopilots at ...2415...
Mon Apr 19 01:24:49 CEST 2010


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
> <twopilots at ...2415...>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 at 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 at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/gambas-user
>
>   




More information about the User mailing list