People could import an csv with >65536 rows and save as XLS, not realizing they will use data
Background: see https://www.bbc.com/news/technology-54423988 and other media reporting about PHE and NHIS using XLS files (or CSV and then importing that to somehwere)...
Hey Heiko, this is a nice UX-Topic, or? *g*
Created attachment 166224 [details] Confirmation when saving a large sheet as XLS We do have a warning, as Paolo points out on Twitter https://twitter.com/Vecchi_Paolo/status/1313138160755527685. Saving to XLS shows this message box, not sure what we can do beyond.
Actually I also wonder what happens when running the application headless. Some conversion from csv to xls using the command line (far-fetched, admitted, but if possible we may need to evoke a warning.
That warning though is shown only when doing a first Save As to .xls. Loading an existing .xls and adding content at positions that can't be saved do not show the warning on a subsequent Save. That should be implemented.
(In reply to Eike Rathke from comment #5) > That warning though is shown only when doing a first Save As to .xls. > Loading an existing .xls and adding content at positions that can't be saved > do not show the warning on a subsequent Save. That should be implemented. And - if I reported correct :) - also - file open - load and CVS - save as XLS only shows the generic non-ODF format warning.
We discussed the topic in the design meeting and found a few situations where a warning is clearly missing. 1. on repeated save operations (see comment 5) + maybe showing an infobar on top helps when user edits a document that has been saved with limitations 2. headless conversion (fill a row with numbers, save as CSV and use a text editor to add some numbers) + soffice --headless --convert-to ods foo.csv => no warning + soffice --headless --convert-to xls foo.ods => no warning (raising the importance because of this) (In reply to Cor Nouws from comment #6) > - file open, load and CVS Should be the same and we show "The data could not be loaded completely because the maximum number of rows per sheet was exceeded."
Please see the discussion in bug 125268 comment 37 and below. I argued that we need a better indications of specific problems detected on import. Unfortunately, it deemed that users should never be allowed to see useful information (we know better, don't we???).
(In reply to Mike Kaganski from comment #8) > we need a better indications of specific problems detected on import. I meant "on export", or course. Sorry.
There was a similar problem with column numbers at bug #123100
(In reply to Gabor Kelemen from comment #10) > There was a similar problem with column numbers at bug #123100 Running soffice --headless --convert-to test.ods test.csv with 1;1... max_col+1 (or using tab instead of semicolon) puts everything in the first cell. Version 6.4 converts without issues while master with debug info throws a lot of warnings. The internal confirmation box of more columns as possible is okay.
(In reply to Heiko Tietze from comment #11) > (In reply to Gabor Kelemen from comment #10) > > There was a similar problem with column numbers at bug #123100 > > Running soffice --headless --convert-to test.ods test.csv with 1;1... > max_col+1 (or using tab instead of semicolon) puts everything in the first > cell. Version 6.4 converts without issues while master with debug info > throws a lot of warnings. How this is related? (and --convert-to doesn't accept output file name, just extension and optional filter settings, which allow you to define which settings to use for CSV import, like separators etc - see https://wiki.openoffice.org/wiki/Documentation/DevGuide/Spreadsheets/Filter_Options)