There is still an issue with the add data entry function If a double return does not register (as is possible when rapidly inputting lots of  data quickly) any simple and move the cursor to the next cell ( ie 2 entries are typed inadvertently into the same cell, Gretl crashes. So, if the user input error occurs during a long series of data all previous inputs are lost. In addition, if the user has not saved any other operation outputs or analysis before the data entry error occurs, all that is lost too.   I would humbly suggest that any data error entry in the Add Data function calls up a data entry error warning rather than crashing Gretl.

On Fri, Jan 24, 2025 at 9:37 AM Sven Schreiber <sven.schreiber(a)fu-berlin.de&gt; wrote: > > Am 24.01.2025 um 12:15 schrieb Brian Revell: > > There is still an issue with the add data entry function If a double return does not register (as is possible when rapidly inputting lots of data quickly) any simple and move the cursor to the next cell ( ie 2 entries are typed inadvertently into the same cell, Gretl crashes. So, if the user input error occurs during a long series of data all previous inputs are lost. In addition, if the user has not saved any other operation outputs or analysis before the data entry error occurs, all that is lost too. I would humbly suggest that any data error entry in the Add Data function calls up a data entry error warning rather than crashing Gretl. > > Well, as I said before, I tried what you described and there wasn't any crash. A crash of course is never intended behavior. Do you have a concrete minimal example with a concrete dataset where this happens, including a description of which series exactly, in which cell exactly, and so on? I too have tried using the GUI data editor on Windows 11, and I couldn't provoke a crash via the sequence Brian describes (or in any other way). So this is a mystery. It may help if we get a really exact, detailed account of what led up to a crash. Allin Cottrell _______________________________________________ Gretl-users mailing list -- gretl-users(a)gretlml.univpm.it To unsubscribe send an email to gretl-users-leave(a)gretlml.univpm.it Website: https://gretlml.univpm.it/postorius/lists/gretl-users.gretlml.univpm.it/

-----Oorspronkelijk bericht----- Van: Riccardo (Jack) Lucchetti <p002264(a)staff.univpm.it&gt; Verzonden: vrijdag 24 januari 2025 17:52 Aan: gretl-users(a)gretlml.univpm.it Onderwerp: [Gretl-users] Re: Add DAta -Data entry Gretl2024d On 24/01/2025 17:21, Brian Revell wrote: > Hi > Here is an example in which a new variable is to be manually entered, > and an entry error is made by insdvertentlyinadvertently typing it > into what was the the preceding entry space . Here's a slight variation I tried on my Win10 virtual machine with 2024d: 1) open gretl 2) create an empty yearly dataset via "nulldata 50" and "setobs 1 1975" at the console 3) go to "Add > New variable" and type in a valid varname 4) click on the cell for the year 1975 and type in a number, then Enter; cursor moves down to 1976 automatically 5) type in a number, then Enter -> gretl freezes I then tried the same with the current snapshot, same thing. ------------------------------------------------------- Riccardo (Jack) Lucchetti

It is an avoidable error, but when entering many observations, we are only himan, and slight errors can be made in failing to press <enter>twice, or for one of the <enter> instructions to be pressed too lightly if working at speed. That's why I suggested an entry error message should intervene if a numeric entry begins instead of the second <enter> to avoid freezing Gretl and losing work. Brian

On 24/01/2025 18:05, Brian Revell wrote: > It is an avoidable error, but when entering many observations, we are > only himan, and slight errors can be made in failing to press > <enter>twice, or for one of the <enter> instructions to be pressed too > lightly if working at speed. That's why I suggested an entry error > message should intervene if a numeric entry begins instead of the second > <enter> to avoid freezing Gretl and losing work. No error message should be necessary, because this is unintended behaviour, which is specific to the 2024c and 2024d Windows clients[*], so 99.99% related to the switch to the new libraries (GTK3 or UCRT). The same routine on 2024b or the current linux version[**] works just fine. [*] I just checked [**] Ditto ------------------------------------------------------- Riccardo (Jack) Lucchetti Dipartimento di Scienze Economiche e Sociali (DiSES) Università Politecnica delle Marche (formerly known as Università di Ancona) r.lucchetti(a)univpm.it http://www2.econ.univpm.it/servizi/hpp/lucchetti ------------------------------------------------------- _______________________________________________ Gretl-users mailing list -- gretl-users(a)gretlml.univpm.it To unsubscribe send an email to gretl-users-leave(a)gretlml.univpm.it Website: https://gretlml.univpm.it/postorius/lists/gretl-users.gretlml.univpm.it/

On Fri, Jan 24, 2025 at 12:19 PM Sven Schreiber <sven.schreiber(a)fu-berlin.de&gt; wrote: > > Now we have a replicable issue, thanks for your detailed report. This is > of course a bug, it's not a user error. Hopefully it can be fixed soon. Can people please try this current snapshot: https://users.wfu.edu/cottrell/gretl/gretl_install-64-msvcrt.exe ? I've tried the data-editing actions described by Brian and Jack and I'm not seeing any problem. This build of gretl uses GTK3 but, as the name suggests, it doesn't use UCRT.

Off-topic: I'd also be interested to hear from anyone who saw gnuplot acting a bit slowly on Windows in recent 64-bit Windows builds. How does this build rate in that respect?

Am 25.01.2025 um 11:52 schrieb Riccardo (Jack) Lucchetti: > On 24/01/2025 22:51, Cottrell, Allin wrote: >> Can people please try this current snapshot: >> https://users.wfu.edu/cottrell/gretl/gretl_install-64-msvcrt.exe ? >> >> I've tried the data-editing actions described by Brian and Jack and >> I'm not seeing any problem. >> >> This build of gretl uses GTK3 but, as the name suggests, it doesn't >> use UCRT. > > Confirmed on my Win10 VM, this one works just fine. Same here, no crash. I also re-checked with the latest "regular" (=UCRT, AFAIK) snapshot from early Januar, and there the problem is present. > >> Off-topic: I'd also be interested to hear from anyone who saw gnuplot >> acting a bit slowly on Windows in recent 64-bit Windows builds. How >> does this build rate in that respect? > > I really don't know, my VM is awfully slow and possible differences > are very hard to appreciate. Sorry. Yes the plotting seems snappier again, like in "the old days" (= up to last summer or fall). Plots appear almost instantaneously. This is on Windows 11. thanks sven _______________________________________________ Gretl-users mailing list -- gretl-users(a)gretlml.univpm.it To unsubscribe send an email to gretl-users-leave(a)gretlml.univpm.it Website: https://gretlml.univpm.it/postorius/lists/gretl-users.gretlml.univpm.it/

At some point we can try to figure out exactly what's wrong with the UCRT build.