Re: [Gambas-user] Setting path in Dialog
Benoit: Excellent! I will remember that for the next time. For now, T Lee Davidson has solved my immediate problem. But just for completeness, here's the info: [System] Gambas=3.8.4 OperatingSystem=Linux Kernel=3.13.0-85-generic Architecture=x86 Distribution=Ubuntu 14.04.4 LTS Desktop=XFCE Theme=Windows Language=en_US.UTF-8 Memory=1948M [Libraries] Cairo=libcairo.so.2.11301.0 Curl=libcurl.so.4.3.0 DBus=libdbus-1.so.3.7.6 GStreamer=libgstreamer-0.10.so.0.30.0 GStreamer=libgstreamer-1.0.so.0.204.0 GTK+2=libgtk-x11-2.0.so.0.2400.23 GTK+3=libgtk-3.so.0.1000.8 OpenGL=libGL.so.1.2.0 Poppler=libpoppler.so.44.0.0 QT4=libQtCore.so.4.8.6 SDL=libSDL-1.2.so.0.11.4 [Environment] CLUTTER_IM_MODULE=xim DBUS_SESSION_BUS_ADDRESS=unix:abstract=/tmp/dbus-KkFIwEuOiM DEFAULTS_PATH=/usr/share/gconf/xubuntu.default.path DESKTOP_SESSION=xubuntu DISPLAY=:0.0 GB_GUI=gb.qt4 GDMSESSION=xubuntu GDM_LANG=en_US GLADE_CATALOG_PATH=: GLADE_MODULE_PATH=: GLADE_PIXMAP_PATH=: GNOME_KEYRING_CONTROL=/run/user/1000/keyring-6CZHEv GNOME_KEYRING_PID=1706 GPG_AGENT_INFO=/run/user/1000/keyring-6CZHEv/gpg:0:1 GTK_IM_MODULE=ibus HOME= IM_CONFIG_PHASE=1 INSTANCE= JOB=dbus LANG=en_US.UTF-8 LANGUAGE=en_US:en LOGNAME= MANDATORY_PATH=/usr/share/gconf/xubuntu.mandatory.path PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games PWD= QT4_IM_MODULE=xim QT_IM_MODULE=xim SELINUX_INIT=YES SESSION=xubuntu SESSIONTYPE= SESSION_MANAGER=local/:@/tmp/.ICE-unix/1921,unix/:/tmp/.ICE-unix/1921 SHELL=/bin/bash SHLVL=0 SSH_AUTH_SOCK=/run/user/1000/keyring-6CZHEv/ssh TEXTDOMAIN=im-config TEXTDOMAINDIR=/usr/share/locale/ TZ=:/etc/localtime UPSTART_EVENTS=started xsession UPSTART_INSTANCE= UPSTART_JOB=startxfce4 UPSTART_SESSION=unix:abstract=/com/ubuntu/upstart-session/1000/1744 USER= XAUTHORITY=/.Xauthority XDG_CONFIG_DIRS=/etc/xdg/xdg-xubuntu:/usr/share/upstart/xdg:/etc/xdg:/etc/xdg XDG_CURRENT_DESKTOP=XFCE XDG_DATA_DIRS=/usr/share/xubuntu:/usr/share/xfce4:/usr/local/share/:/usr/share/:/usr/share XDG_GREETER_DATA_DIR=/var/lib/lightdm-data/ XDG_MENU_PREFIX=xfce- XDG_RUNTIME_DIR=/run/user/1000 XDG_SEAT=seat0 XDG_SEAT_PATH=/org/freedesktop/DisplayManager/Seat0 XDG_SESSION_ID=c2 XDG_SESSION_PATH=/org/freedesktop/DisplayManager/Session0 XDG_VTNR=7 XMODIFIERS=@im=ibus Thanks! Ed K. I On 04/27/2016 06:47 PM, Benoît Minisini wrote: > Le 28/04/2016 03:04, Ed & Clare Kelm a écrit : >> Benoit: >> >> Thanks for the prompt reply. My project has 8K lines of code, so I will >> make a little test project. >> >> Can you provide me a link which shows how to provide the info you need? >> >> Ed K. > Menu "?" -> "System information" in the IDE. > -- Find and fix application performance issues faster with Applications Manager Applications Manager provides deep performance insights into multiple tiers of your business applications. It resolves application problems quickly and reduces your MTTR. Get your free trial! https://ad.doubleclick.net/ddm/clk/302982198;130105516;z ___ Gambas-user mailing list Gambas-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/gambas-user
Re: [Gambas-user] Setting path in Dialog
T Lee: Home run! 1. The "~ shortcut" works fine when the program directly opens a file. 2. When I use your syntax in the Dialog.Path statement, everything works correctly! Many thanks for solving my problem! Ed K. On 04/27/2016 06:01 PM, T Lee Davidson wrote: > I believe the tilde does not work as a shortcut for user's home directory. > > You should probably use: Dialog.Path = User.Home &/ "Documents/ED/NEC Antenna > Files/" > > > On 04/27/2016 08:34 PM, Ed & Clare Kelm wrote: >> I have the same problem as Rolf. (2016-01-19 17:11:18) >> >> Setting dialog.path does not work. Instead, the resulting path is >> always the location of the project. >> >> My project is located in ~/Documents/Gambas Projects/EDNEC/ >> >> In the project is this code snippet: >> >> ** >> Dialog.Path = "~/Documents/ED/NEC Antenna Files/" >> Dialog.Title = "Select an Antenna File to Open" >> Dialog.Filter = ["*.txt; *.TXT", "Text Files", "*.NEC", "NEC Input Files"] >> >> Print Dialog.Path >> >> If Dialog.OpenFile() Then Return >> ** >> >> When it executes, the correct path is printed to the IDE, the correct >> title appears on the Open dialog, and the correct filter appears in the >> Open dialog. However, the path in the Open dialog is ~/Documents/Gambas >> Projects/EDNEC/. >> >> I am using: >> >> Gambas 3.8.4 >> Xubuntu 14.04 >> >> Any help for this? >> >> Thanks! >> >> Ed K. -- Find and fix application performance issues faster with Applications Manager Applications Manager provides deep performance insights into multiple tiers of your business applications. It resolves application problems quickly and reduces your MTTR. Get your free trial! https://ad.doubleclick.net/ddm/clk/302982198;130105516;z ___ Gambas-user mailing list Gambas-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/gambas-user
Re: [Gambas-user] Setting path in Dialog
Benoit: Thanks for the prompt reply. My project has 8K lines of code, so I will make a little test project. Can you provide me a link which shows how to provide the info you need? Ed K. On 04/27/2016 05:45 PM, Benoît Minisini wrote: > Le 28/04/2016 02:34, Ed & Clare Kelm a écrit : >> I have the same problem as Rolf. (2016-01-19 17:11:18) >> >> Setting dialog.path does not work. Instead, the resulting path is >> always the location of the project. >> >> My project is located in ~/Documents/Gambas Projects/EDNEC/ >> >> In the project is this code snippet: >> >> ** >> Dialog.Path = "~/Documents/ED/NEC Antenna Files/" >> Dialog.Title = "Select an Antenna File to Open" >> Dialog.Filter = ["*.txt; *.TXT", "Text Files", "*.NEC", "NEC Input Files"] >> >> Print Dialog.Path >> >> If Dialog.OpenFile() Then Return >> ** >> >> When it executes, the correct path is printed to the IDE, the correct >> title appears on the Open dialog, and the correct filter appears in the >> Open dialog. However, the path in the Open dialog is ~/Documents/Gambas >> Projects/EDNEC/. >> >> I am using: >> >> Gambas 3.8.4 >> Xubuntu 14.04 >> >> Any help for this? >> >> Thanks! >> >> Ed K. > As usual, please provide a full project that reproduces the bug, and > your full system information. > > Because Dialog.OpenFile() can actually choose between five different > dialogs, and one with four different toolkits. > > Regards, > -- Find and fix application performance issues faster with Applications Manager Applications Manager provides deep performance insights into multiple tiers of your business applications. It resolves application problems quickly and reduces your MTTR. Get your free trial! https://ad.doubleclick.net/ddm/clk/302982198;130105516;z ___ Gambas-user mailing list Gambas-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/gambas-user
Re: [Gambas-user] Setting path in Dialog
I have the same problem as Rolf. (2016-01-19 17:11:18) Setting dialog.path does not work. Instead, the resulting path is always the location of the project. My project is located in ~/Documents/Gambas Projects/EDNEC/ In the project is this code snippet: ** Dialog.Path = "~/Documents/ED/NEC Antenna Files/" Dialog.Title = "Select an Antenna File to Open" Dialog.Filter = ["*.txt; *.TXT", "Text Files", "*.NEC", "NEC Input Files"] Print Dialog.Path If Dialog.OpenFile() Then Return ** When it executes, the correct path is printed to the IDE, the correct title appears on the Open dialog, and the correct filter appears in the Open dialog. However, the path in the Open dialog is ~/Documents/Gambas Projects/EDNEC/. I am using: Gambas 3.8.4 Xubuntu 14.04 Any help for this? Thanks! Ed K. -- Find and fix application performance issues faster with Applications Manager Applications Manager provides deep performance insights into multiple tiers of your business applications. It resolves application problems quickly and reduces your MTTR. Get your free trial! https://ad.doubleclick.net/ddm/clk/302982198;130105516;z ___ Gambas-user mailing list Gambas-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/gambas-user
Re: [Gambas-user] two separate groups of RadioButton same Form
Nicolas: Put each group of buttons, (or at least one group), in a frame. Ed K. Nicolas Koch wrote: So I had taken a year hiatus away from the GAMBAS community due to the military and am finally back home coding again. :D I gotta tell you I really miss and love coding in GAMBAS. anyways on to my question... I have a Form and I want to have two separate groups of RadioButtons. In each group of RadioButtons on the same Form only one can be true, the rest will be false. How would I accomplish this? I had tried separating using panels, but I suppose I made a mistake somewhere. Thanks again to any and all who respond. Nick -- Oracle to DB2 Conversion Guide: Learn learn about native support for PL/SQL, new data types, scalar functions, improved concurrency, built-in packages, OCI, SQL*Plus, data movement tools, best practices and more. http://p.sf.net/sfu/oracle-sfdev2dev ___ Gambas-user mailing list Gambas-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/gambas-user -- Oracle to DB2 Conversion Guide: Learn learn about native support for PL/SQL, new data types, scalar functions, improved concurrency, built-in packages, OCI, SQL*Plus, data movement tools, best practices and more. http://p.sf.net/sfu/oracle-sfdev2dev ___ Gambas-user mailing list Gambas-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/gambas-user
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
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
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
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
[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
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
