Many thanksOne still has much to learn. Will try your suggestion to satisfy my curiosity re xlsx format. Might saving in the old xls format avoid the problem of ghost cells, though less of a general solution than the line1 string you suggest.B_______________________________________________On Tue, 16 Dec 2025, 08:23 Riccardo (Jack) Lucchetti, <p002264@staff.univpm.it> wrote:_______________________________________________On 15/12/2025 22:35, Brian Revell wrote:
Thanks for letting me know that. Explains why Gretl in turn was confusing me. Might saving it as a CSV file have been less problematic to 2025c. Though as I said, uploads of xlsx files to earlier versions of Gretl have always been straightforward.Just for future reference, if you want to have a look at what you really get inside an xlsx file, here's what you can do:
1. Rename the file and change its extension to "zip" (eg, I renamed the file you sent us to "Brian.zip")
2. Open the zip file with any application you want; if you're on windows, I guess you might as well double-click on it
3. You'll see a hierarchical structure of files and folders. Go to "xl/worksheets" and you'll see a file named "sheet1.xml"
4. You may open that file with any program that handles text. Notepad, Word, whatever. However, I would suggest firefox, that handles the xml format quite nicely (the absence of line breaks may be problematic otherwise).
5. Note that each row has a "spans" attribute that tells you how many non-empty columns you get. In your case, this number is 12 (I don't know why)
6. If you navigate to row 14, you'll see that the L14 cell contains the value "4", which is however marked as a shared string (t="s"). This is obviously spurious in this case and you can't expect gretl to figure out that you didn't really mean to put something invisible in there.
If you do this, you'll see clearly why the xlsx format is not really ideal for storing data: some (most?) of the information it contains is invisible to the naked eye, so to speak, and this may cause problems when reading its contents. As you suggested, CSV is much better in that respect.
Having said this, I'm wondering whether we can somehow handle cases like this via a policy of considering as genuine data columns only the ones that have a suitable string on row 1, and ignoring the rest.
------------------------------------------------------- Riccardo (Jack) Lucchetti Dipartimento di Scienze Economiche e Sociali (DiSES) Università Politecnica delle Marche (formerly known as Università di Ancona) r.lucchetti@univpm.it http://www2.econ.univpm.it/servizi/hpp/lucchetti -------------------------------------------------------
Gretl-users mailing list -- gretl-users@gretlml.univpm.it
To unsubscribe send an email to gretl-users-leave@gretlml.univpm.it
Website: https://gretlml.univpm.it/postorius/lists/gretl-users.gretlml.univpm.it/
Gretl-users mailing list -- gretl-users@gretlml.univpm.it
To unsubscribe send an email to gretl-users-leave@gretlml.univpm.it
Website: https://gretlml.univpm.it/postorius/lists/gretl-users.gretlml.univpm.it/