Re: [Gambas-user] EOF problem
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#174; 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
Re: [Gambas-user] EOF problem
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
Re: [Gambas-user] EOF problem
Hi Ed, After many tries, I managed to recreate your problem. It happens with your code and the code supplied by Dimitris. I am using Ubuntu 9.04, Kernel 2.6.28-18, Gambas 2.20.2, QT I have not managed to figure out the cause yet. I will do more tests and get back to you. Regards Les Hardy Ed Clare Kelm wrote: Hi! I'm having a problem reliably reading a text file. I am using: Panasonic CF-51 Toughbook Ubuntu 9.04 , Kernel 2.6.28-18 Gambas 2.8, QT Below is the code for a test program which demonstrates the problem. This is a simple form, with one button, and one label. The only code is the Button1_click event shown. The file testdat.txt contained in Fname is a text file with one short line of text, created with GEDIT. One would expect that clicking Button1 would open the file, read the line of text, and place it into label1. Indeed, this is exactly what happens roughly 4 times out of 5. However, sometimes the file comes up empty, with an immediate EOF. When the program is first started from the IDE, if it works correctly the first time, it will do so every time the button is clicked. However, if it fails (indicates EOF) the first time, it will fail everytime the button is clicked. Stopping the program and restarting it will roll the dice anew. There does not seem to be any pattern to the failure. It might happen twice in a row, it might not happen for 10 starts. Does anybody have any ideas? Is this an Ubuntu issue? Thanks! Ed K. 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 -- Download Intel#174; 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
Re: [Gambas-user] EOF problem
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. The following code gets around the problem. It's not ideal, but it does work. Maybe someone else can improve on it. Regards Les Hardy PUBLIC SUB Button1_Click() DIM tfile AS File DIM Fname AS String DIM t, txt AS String Label1.text = Fname = /home/les/Documents/testdat.txt tfile = OPEN Fname FOR READ IF NOT Eof(tfile) THEN LINE INPUT #tfile, t txt = IIf(Trim(t) , t, EOF) Label1.text = txt ELSE Label1.text = EOF ENDIF CLOSE #tfile END Ed Clare Kelm wrote: Hi! I'm having a problem reliably reading a text file. I am using: Panasonic CF-51 Toughbook Ubuntu 9.04 , Kernel 2.6.28-18 Gambas 2.8, QT Below is the code for a test program which demonstrates the problem. This is a simple form, with one button, and one label. The only code is the Button1_click event shown. The file testdat.txt contained in Fname is a text file with one short line of text, created with GEDIT. One would expect that clicking Button1 would open the file, read the line of text, and place it into label1. Indeed, this is exactly what happens roughly 4 times out of 5. However, sometimes the file comes up empty, with an immediate EOF. When the program is first started from the IDE, if it works correctly the first time, it will do so every time the button is clicked. However, if it fails (indicates EOF) the first time, it will fail everytime the button is clicked. Stopping the program and restarting it will roll the dice anew. There does not seem to be any pattern to the failure. It might happen twice in a row, it might not happen for 10 starts. Does anybody have any ideas? Is this an Ubuntu issue? Thanks! Ed K. 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 -- Download Intel#174; 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
Re: [Gambas-user] EOF problem
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... Given such a file, at first EOF is false; doing a LINE INPUT an empty line is read, then EOF turns true. Or, at least, it should go this way. Regards, -- Doriano Blengino Listen twice before you speak. This is why we have two ears, but only one mouth. -- Download Intel#174; 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
Re: [Gambas-user] EOF problem
Dimitris Les: First Dimitris: OK, I pasted in your code. I had to change temp to tmp, because Temp seems to be a Keyword. With that out of the way, the problem persists. When it fails, I get EOF both in label1 and the debug window. When it works OK, I get a blank label1 and the text appears in the debug window. The state of being at EOF seems to arise (randomly) as soon as the file is opened. After that, everthing happens as one would expect - an EOF directs execution to the EOF stuff, and lack of EOF executes the text reading stuff. I can't believe this is a common problem - by now hundreds of people would have noticed that their database and any other programs reading a text file don't work reliably. There's got to be something peculiar about my installation. Now to Les: It still fails for me with your code. To clarify a little, the problem is that the file is detected as empty when it's not, not the other way around. Your code works like mine - when the file is opened it may randomly immediately come up as being at EOF. The IF not EOF... statement then sends it directly to the ELSE, and the game is over. If you can reproduce my problem by reading the same file over and over, closing the program after every try, but using Gambas 2.20.2, then I've got to suspect Ubuntu, at least the 9.04 I have. If you cannot, then I should upgrade Gambas. I suppose a shotgun approach might be to upgrade to Ubuntu 9.10 AND Gambas 2.20.2. Lastly, I don't think having a file with just a single 0A should be called empty. To me EOF means just that, End of File - no more data to be read. I would consider the 0A to be data, a blank line if you like. So, I think Gambas not raising EOF on such a file until the line is read is appropriate. Both: I'll chew on this for a few days, and then think about upgrading something. Thanks for your efforts! Ed K. Les Hardy wrote: 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. The following code gets around the problem. It's not ideal, but it does work. Maybe someone else can improve on it. Regards Les Hardy PUBLIC SUB Button1_Click() DIM tfile AS File DIM Fname AS String DIM t, txt AS String Label1.text = Fname = /home/les/Documents/testdat.txt tfile = OPEN Fname FOR READ IF NOT Eof(tfile) THEN LINE INPUT #tfile, t txt = IIf(Trim(t) , t, EOF) Label1.text = txt ELSE Label1.text = EOF ENDIF CLOSE #tfile END Ed Clare Kelm wrote: Hi! I'm having a problem reliably reading a text file. I am using: Panasonic CF-51 Toughbook Ubuntu 9.04 , Kernel 2.6.28-18 Gambas 2.8, QT Below is the code for a test program which demonstrates the problem. This is a simple form, with one button, and one label. The only code is the Button1_click event shown. The file testdat.txt contained in Fname is a text file with one short line of text, created with GEDIT. One would expect that clicking Button1 would open the file, read the line of text, and place it into label1. Indeed, this is exactly what happens roughly 4 times out of 5. However, sometimes the file comes up empty, with an immediate EOF. When the program is first started from the IDE, if it works correctly the first time, it will do so every time the button is clicked. However, if it fails (indicates EOF) the first time, it will fail everytime the button is clicked. Stopping the program and restarting it will roll the dice anew. There does not seem to be any pattern to the failure. It might happen twice in a row, it might not happen for 10 starts. Does anybody have any ideas? Is this an Ubuntu issue? Thanks! Ed K. 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 -- Download Intel#174; 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
Re: [Gambas-user] EOF problem
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... Given such a file, at first EOF is false; doing a LINE INPUT an empty line is read, then EOF turns true. Or, at least, it should go this way. Regards, 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. Regards Les Hardy -- Download Intel#174; 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
Re: [Gambas-user] EOF problem
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, -- Doriano Blengino Listen twice before you speak. This is why we have two ears, but only one mouth. -- Download Intel#174; 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
Re: [Gambas-user] EOF problem
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#174; 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
Re: [Gambas-user] EOF problem
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.netwrote: 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
Re: [Gambas-user] EOF problem
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.netwrote: 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
[Gambas-user] EOF problem
Hi! I'm having a problem reliably reading a text file. I am using: Panasonic CF-51 Toughbook Ubuntu 9.04 , Kernel 2.6.28-18 Gambas 2.8, QT Below is the code for a test program which demonstrates the problem. This is a simple form, with one button, and one label. The only code is the Button1_click event shown. The file testdat.txt contained in Fname is a text file with one short line of text, created with GEDIT. One would expect that clicking Button1 would open the file, read the line of text, and place it into label1. Indeed, this is exactly what happens roughly 4 times out of 5. However, sometimes the file comes up empty, with an immediate EOF. When the program is first started from the IDE, if it works correctly the first time, it will do so every time the button is clicked. However, if it fails (indicates EOF) the first time, it will fail everytime the button is clicked. Stopping the program and restarting it will roll the dice anew. There does not seem to be any pattern to the failure. It might happen twice in a row, it might not happen for 10 starts. Does anybody have any ideas? Is this an Ubuntu issue? Thanks! Ed K. 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 -- Download Intel#174; 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
Re: [Gambas-user] EOF problem
Hi! I'm having a problem reliably reading a text file. I am using: Panasonic CF-51 Toughbook Ubuntu 9.04 , Kernel 2.6.28-18 Gambas 2.8, QT Below is the code for a test program which demonstrates the problem. This is a simple form, with one button, and one label. The only code is the Button1_click event shown. The file testdat.txt contained in Fname is a text file with one short line of text, created with GEDIT. One would expect that clicking Button1 would open the file, read the line of text, and place it into label1. Indeed, this is exactly what happens roughly 4 times out of 5. However, sometimes the file comes up empty, with an immediate EOF. When the program is first started from the IDE, if it works correctly the first time, it will do so every time the button is clicked. However, if it fails (indicates EOF) the first time, it will fail everytime the button is clicked. Stopping the program and restarting it will roll the dice anew. There does not seem to be any pattern to the failure. It might happen twice in a row, it might not happen for 10 starts. Does anybody have any ideas? Is this an Ubuntu issue? Thanks! Ed K. 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 I cannot reproduce the problem with the same code. Does it occur whatever the contents of 'testdat.txt' is? Can you try the latest version of Gambas 2? -- Benoît Minisini -- Download Intel#174; 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
Re: [Gambas-user] EOF problem
Thanks for the quick reply! 1. The problem is independent of the contents of the text file. 2. I tried a more complicated test program in which there are TWO buttons, and TWO different text files. This behaves similarly; most of the time, failure of one button/file will be accompanied by failure of the other, but not always. Very occasionally, one button/file will work, one will fail. 3. According to Synaptics Package Manager I have the latest version of Gambas available, called 2.8.2-1build1 - if there is a newer version, how would I find and install it? 4. Would it be worth trying an upgrade to Ubuntu 9.10? Regards, Ed K. Benoît Minisini wrote: Hi! I'm having a problem reliably reading a text file. I am using: Panasonic CF-51 Toughbook Ubuntu 9.04 , Kernel 2.6.28-18 Gambas 2.8, QT Below is the code for a test program which demonstrates the problem. This is a simple form, with one button, and one label. The only code is the Button1_click event shown. The file testdat.txt contained in Fname is a text file with one short line of text, created with GEDIT. One would expect that clicking Button1 would open the file, read the line of text, and place it into label1. Indeed, this is exactly what happens roughly 4 times out of 5. However, sometimes the file comes up empty, with an immediate EOF. When the program is first started from the IDE, if it works correctly the first time, it will do so every time the button is clicked. However, if it fails (indicates EOF) the first time, it will fail everytime the button is clicked. Stopping the program and restarting it will roll the dice anew. There does not seem to be any pattern to the failure. It might happen twice in a row, it might not happen for 10 starts. Does anybody have any ideas? Is this an Ubuntu issue? Thanks! Ed K. 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 I cannot reproduce the problem with the same code. Does it occur whatever the contents of 'testdat.txt' is? Can you try the latest version of Gambas 2? -- Download Intel#174; 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
Re: [Gambas-user] EOF problem
Ed can you try this and tell us if it still doesn't work? PUBLIC SUB Button1_Click() DIM tfile AS File DIM Fname AS String Dim temp AS String Fname = /home/us/Documents/testdat.txt tfile = OPEN Fname FOR READ label1.Text = IF Eof(tfile) THEN label1.Text = EOF Print EOF ELSE LINE INPUT #tfile, temp Print temp END IF CLOSE #tfile END Watch the IDE's debug window to see what's being printed as the file is being read If this doesn't work too then you could try to update your version of Gambas2 since the latest stable version is 2.20.2 I hope this helps Regard Dimitris On Sun, Apr 18, 2010 at 2:25 AM, Ed Clare Kelm twopil...@interisland.netwrote: Thanks for the quick reply! 1. The problem is independent of the contents of the text file. 2. I tried a more complicated test program in which there are TWO buttons, and TWO different text files. This behaves similarly; most of the time, failure of one button/file will be accompanied by failure of the other, but not always. Very occasionally, one button/file will work, one will fail. 3. According to Synaptics Package Manager I have the latest version of Gambas available, called 2.8.2-1build1 - if there is a newer version, how would I find and install it? 4. Would it be worth trying an upgrade to Ubuntu 9.10? Regards, Ed K. Benoît Minisini wrote: Hi! I'm having a problem reliably reading a text file. I am using: Panasonic CF-51 Toughbook Ubuntu 9.04 , Kernel 2.6.28-18 Gambas 2.8, QT Below is the code for a test program which demonstrates the problem. This is a simple form, with one button, and one label. The only code is the Button1_click event shown. The file testdat.txt contained in Fname is a text file with one short line of text, created with GEDIT. One would expect that clicking Button1 would open the file, read the line of text, and place it into label1. Indeed, this is exactly what happens roughly 4 times out of 5. However, sometimes the file comes up empty, with an immediate EOF. When the program is first started from the IDE, if it works correctly the first time, it will do so every time the button is clicked. However, if it fails (indicates EOF) the first time, it will fail everytime the button is clicked. Stopping the program and restarting it will roll the dice anew. There does not seem to be any pattern to the failure. It might happen twice in a row, it might not happen for 10 starts. Does anybody have any ideas? Is this an Ubuntu issue? Thanks! Ed K. 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 I cannot reproduce the problem with the same code. Does it occur whatever the contents of 'testdat.txt' is? Can you try the latest version of Gambas 2? -- Download Intel#174; 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#174; 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
