[Description] When I paste (Ctrl+Alt+Shift+V) over existing values, and the pasted values have an empty line, the line is cleared, but not the last value of the line. [How to test] TabA below is the original table. TabB is a new changed version to be copied over TabA (line a gone, line e added), TabC is the result after TabB was pasted as unformatted Text over TabA. You can see in the empty line the last value (b-3) is still present in the line that was supposed to be empty. [Test sample "tables"] TabA Legend;1;2;3 a;a-1;a-2;a-3 b;b-1;b-2;b-3 empty;;; d;d-1;d-2;d-3 TabB Legend;1;2;3 b;b-1;b-2;b-3 empty;;; d;d-1;d-2;d-3 e;e-1;e-2;e-3 TabC Legend;1;2;3 b;b-1;b-2;b-3 empty;;;b-3 d;d-1;d-2;d-3 e;e-1;e-2;e-3 To test, paste TabA in a sheet, then paste TabB as unformatted text over it. The empty line is not empty. [Reproducible] Always
OTOH, the behavior allows to overwrite prior values with newer values without "deleting" prior values when a new value does not exist – a differential replacement. So, there are cases for which the current behavior is useful. One possible alternative workaround to the case described in comment 0 would be to have some other character instead of "empty" fields/cells. For instance: * with a space character: Legend;1;2;3 b;b-1;b-2;b-3 empty; ; ; d;d-1;d-2;d-3 e;e-1;e-2;e-3 * with an underscore character: Legend;1;2;3 b;b-1;b-2;b-3 empty;_;_;_ d;d-1;d-2;d-3 e;e-1;e-2;e-3 which allows to replace the prior values, and then you could perform a (Find&)Replace action on the selected special character. IMO, I would not change the current behavior.
But why does this behavior only affect the last column of a line? This is not logical. Pasting an empty line so it deletes all values in a formerly filled line except for the last one in that line, when is this behavior useful? Why not the 3rd one instead of the last column? ;-) The lines -with values or empty- come from a script that writes out the values found and an empty value is a valid (missing) value. An empty value should be a valid value in libreoffice-calc in all fields of a line, so changing it to blank or _ is a solution which is not really how it should be treated, it's not empty then. What is more, if you want to keep the former values, you can tic "Skip empty cells". Which I didn't, because it should not. IMHO, I would recommend to change the current behavior - I think it's a bug.
(In reply to MBS from comment #2) > But why does this behavior only affect the last column of a line? > This is not logical. FWIW, that is not what I see. The behavior I see is the same for every column/row/cell/field: when there is no new value (i.e. an empty value in the field is about to be pasted), the prior value is kept (not replaced) as it was before. IOW, for me it is: Version: 7.6.1.2 (X86_64) / LibreOffice Community Build ID: f5defcebd022c5bc36bbb79be232cb6926d8f674 CPU threads: 4; OS: Windows 10.0 Build 19045; UI render: Skia/Raster; VCL: win Locale: en-US (es_AR); UI: en-US Calc: CL threaded TabC Legend;1;2;3 b;b-1;b-2;b-3 empty;b-1;b-2;b-3 d;d-1;d-2;d-3 e;e-1;e-2;e-3 which is not the same as in your comment 0. Moreover, with the current behavior you could simply delete the original data ("TabA") from the spreadsheet and paste the new data ("TabB"), obtaining effectively what you want. Or am I misunderstanding something? Please open LO > menu Help > About, click the icon in that dialogue in order to copy the version information to the clipboard. Then post a new comment in this bug report and paste the info in the new comment.
(In reply to MBS from comment #2) > so > changing it to blank or _ is a solution which is not really how it should be > treated, it's not empty then. But that was only _part_ of the workaround; then you could replace the special character (e.g. underscore) with F&R. (In reply to MBS from comment #2) > What is more, if you want to keep the former values, you can tic "Skip empty > cells". Which I didn't, because it should not. I'm not sure I understand what you meant there. Anyway, since this is about a bug report and I am not seeing the same behavior as you see, we should wait for your version information I requested, and/or other users being able to replicate your behavior.
Created attachment 190965 [details] 1st used libreoffice version That's the libreoffice version I'm using
Created attachment 190966 [details] 2nd used libreoffice version this is another version of libreoffice I used, Test results are the same.
Created attachment 190967 [details] This is the libreoffice menu I see Alt-Ctrl-V This is the menu I see, when I paste it using the right mouse button or Alt-Ctrl-V
Repro since LO 5.3. Not repro on 5.2.0.4 and older. I'm not sure whether this is an implementation error, or a regression. STR: 1. Select the following text and copy it to the clipboard ([CTRL]+[C]): Legend;1;2;3 a;a-1;a-2;a-3 b;b-1;b-2;b-3 empty;;; d;d-1;d-2;d-3 2. Open new Calc. 3. In Calc, menu Edit > Paste Special > Unformatted text (OK). 4. In the "text Import" dialogue, select _only_ the check box separated by semicolon; *ALL* the other options/settings/check boxes shall/must be OFF. OK. 5. Select the following text and copy it to the clipboard ([CTRL]+[C]): Legend;1;2;3 b;b-1;b-2;b-3 empty;;; d;d-1;d-2;d-3 e;e-1;e-2;e-3 6. In Calc, menu Edit > Paste Special > Unformatted text (OK). 7. In the "text Import" dialogue, select _only_ the check box separated by semicolon; *ALL* the other options/settings/check boxes shall/must be OFF. OK. Until LO 5.2.0.4, the result is (as expected): Legend;1;2;3 b;b-1;b-2;b-3 empty;b-1;b-2;b-3 d;d-1;d-2;d-3 e;e-1;e-2;e-3 Since LO 5.3, the result is inconsistent in the last column for empty/blank new fields (3rd row): Legend;1;2;3 b;b-1;b-2;b-3 empty;;;b-3 d;d-1;d-2;d-3 e;e-1;e-2;e-3 With these settings in the import dialogue, IMO the result should had been as it was before, in LO 5.2.0.4 and older. Having said that, it is not entirely clear what should be the expected result when the "skip empty cells" option is used in the import dialogue. At any rate, a differential replacement should be possible with some combination of settings (as opposed to a complete replacement, with some other combination of settings in the import dialogue). @MBS, Please next time follow the questions/instructions; the version information can be copied as text in new comments and there is no need to add screenshots just for that. @MBS, Are you really assigning this report to yourself, in order to work on it?
> @MBS, Are you really assigning this report to yourself, in order to work on it? Aww, no, I'm not able to work on it! :-O I'm just a user (complaining), not native in English, struggling with the WIKI (TLDR). Please assign it to someone able to fix it or to decide to state this as a wanted phenomenon. How to change this? default? Can you change this? Concerning your description: > Until LO 5.2.0.4, the result is (as expected): > > Legend;1;2;3 > b;b-1;b-2;b-3 > empty;b-1;b-2;b-3 > d;d-1;d-2;d-3 > e;e-1;e-2;e-3 IMHO this is NOT what was to expect (unless "skip empty cells" was ticked), since the source contained an empty line (empty;;;) which is now NOT empty after the source was copied to the target. The "skip empty cells" option allows to fix a target table with new values (changed or extending the table) and leave the "good" values in the target by pasting empty fields over it, then the former values remain in the target. > With these settings in the import dialogue, IMO the result should had been as it was before, in LO 5.2.0.4 and older. I disagree with that. It should result in this: Legend;1;2;3 b;b-1;b-2;b-3 empty;;; d;d-1;d-2;d-3 e;e-1;e-2;e-3 [skip empty cells] btw when the "skip empty cells" option was ticked the result from comment 8 would be: Legend;1;2;3 b;b-1;b-2;b-3 empty;b-1;b-2;b-3 d;d-1;d-2;d-3 e;e-1;e-2;e-3 all source cells with values overwrite existing target cells (updating them) and empty ones from source will remain untouched in the target. Maybe this is the differential replacement you were looking for?
(In reply to MBS from comment #9) > Concerning your description: > > > Until LO 5.2.0.4, the result is (as expected): > > > > Legend;1;2;3 > > b;b-1;b-2;b-3 > > empty;b-1;b-2;b-3 > > d;d-1;d-2;d-3 > > e;e-1;e-2;e-3 > > IMHO this is NOT what was to expect (unless "skip empty cells" was ticked), In older LO versions, there was no "skip empty cells" option in the import text dialogue. That was the expected result at that time, because that was the way it worked back then. For similar reasons, the STR in comment 8 do not include shortcuts or descriptions of dialogues, but rather a hint of steps that are relatively easy to follow in whichever version of LO – there are differences in shortcuts, UI and available options, depending on LO version. > The "skip empty cells" option allows to fix a target table with new values > (changed or extending the table) and leave the "good" values in the target > by pasting empty fields over it, then the former values remain in the target. > > > With these settings in the import dialogue, IMO the result should had been as it was before, in LO 5.2.0.4 and older. > I disagree with that. > > It should result in this: > > Legend;1;2;3 > b;b-1;b-2;b-3 > empty;;; > d;d-1;d-2;d-3 > e;e-1;e-2;e-3 > > [skip empty cells] > btw when the "skip empty cells" option was ticked the result from comment 8 > would be: > > Legend;1;2;3 > b;b-1;b-2;b-3 > empty;b-1;b-2;b-3 > d;d-1;d-2;d-3 > e;e-1;e-2;e-3 > > all source cells with values overwrite existing target cells (updating them) > and empty ones from source will remain untouched in the target. > Maybe this is the differential replacement you were looking for? Right. The tool tip on the "skip empty cells" option says: "If enabled, blank cells in source will not override the target." (For this bug report, I would add an emphasis on the "source" term, and the fact that the source in this case is not really "cells" until the Text Import dialogue treats it in such way.) So, with LO 7.6, the result of the STR from comment 8 should be: Legend;1;2;3 b;b-1;b-2;b-3 empty;;; d;d-1;d-2;d-3 e;e-1;e-2;e-3 whereas with the "skip empty cells" option set ON, the result should be: Legend;1;2;3 b;b-1;b-2;b-3 empty;b-1;b-2;b-3 d;d-1;d-2;d-3 e;e-1;e-2;e-3 Either way, the reported bug is indeed present, and now we are clear about the _current_ (as of LO 7.6) expected results. I am still not sure whether this is an "implementation error" or a "regression".
If "Skip empty cells" is NOT checked, there is a bug in the last column *** This bug has been marked as a duplicate of bug 129701 ***