[Gambas-user] EOF problem

Mon Apr 19 17:38:10 CEST 2010

Doriano:

Your words were perfectly appropriate, and I understood them and 
appreciate the support!

Thanks!

Yes, I wish EOF would work properly - it would make moving the code from 
VB6 to Gambas less trouble, since the VB6 code uses EOF.  I really need 
to try updating Ubuntu and Gambas I guess, to see if the problem can be 
cured that way. 

Regards,

Ed K.

Doriano Blengino wrote:
> Ed & Clare Kelm ha scritto:
> I was feeling that my words could be seemed not appropriate. In fact, I 
> added that "our friends know what they are doing", and labeled those 
> things as "very little thing", knowing in my mind that was experimental 
> code  to debug some strange behavior. Sorry for that. I did that to 
> stress that this code:
>   
>> 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
>>    
>>     
> has nothing wrong for me. And if the previous code "was written with EOF 
> at the start", it is simply because there is no other way to go. Happy 
> to know that file.load() seems to solve - anyway if that EOF has a bug, 
> it is a harmful one.
>
> Regards,
> Doriano
>   
>> 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
>
>   