Steps how to reproduce with "LibreOffice 3.5.0 RC3 German UI/Locale [Build-ID: 7e68ba2-a744ebf-1f241b7-c506db1-7d53735] on German WIN7 Home Premium (64bit): 0. Download / save attached "samplesource.ods" 1. open "samplesource.ods" 2. Select A1:G10 (with pushed left mouse button, doesn't matter how) 3. <contro+c> for copy (doesn't matter how) 4. Menu 'File -> New -> Text Document' > New WRITER document appears 5. <control+v> for paste Expected: complete range visible with green and red cell borders, yellow ellipse, ... Actual: only cells C5:D6 shown, no further contents pasted (check OLE object). Same with paste special as GDI metafile, bitmap, ... Same effect if you paste to WRITER document of a more early version. Works fine for paste to other spreadsheet or sheet in document. Still worked fine for copy from 3.5.0 beta1 [Reproducible] with "LibreOffice 3.5.0 RC2 German UI/Locale [Build-ID: e371a95-bf68a13-5a1aa2b-d3c1ae9-b938258] on German WIN7 Home Premium (64bit). Related to "Bug 40262 - incorrect copy"?
Created attachment 56850 [details] Sample Source Document See original report
Ok, this case is a bit tricky. We now only copy the area that contains content because otherwise external applications will add a lot of empty cells if you selected a too big area, e.g. a whole row. Noe the tricky part is what is a non empty cell and right now we calla non empty cell a cell that has cell content, either a value, string, formula or a note. I'm not sure if this would be a good idea to include empty cells that have a background color since this will again create problems with too large areas where for example the whole sheet is colored. I fear that for this problem we won't find a perfect solution.
IMHO priority should have to hold predictable and consistent behavior in CALC, and what I see here is very strange and inconsistent, I believe nobody will expect these results. @Markus: Fix for what Bugzilla Bug numbers causes problems of this bug?
*** Bug 46913 has been marked as a duplicate of this bug. ***
(In reply to comment #3) > IMHO priority should have to hold predictable and consistent behavior in CALC, > and what I see here is very strange and inconsistent, I believe nobody will > expect these results. > > @Markus: > Fix for what Bugzilla Bug numbers causes problems of this bug? n#677811 and a more recent commit from me. The problem is that if you copy empty cells and paste them to an external program( writer, mail, ... ) you get more or less a large list of useless data so we only copy the area with content to the copy document. This is does not affect Calc itself. Calc uses a totally different way to access the copy/paste data which is not related to the way we save data for external use. Calc uses an internal copy/paste document which contains all information that were in the original document.
When can we expect a fixed version. Calc has become unusable!
When can we expect a fixed version? Calc has become unusable!
Why is there no activity on this bug? Basic editing functionality is broken. The code introducing this bug has to be rejected from the code base asap. The summary of this bug is bad. All full wor operations like drag&drop, rearrange... do not work anymore!
correction: "full row"
NEW due to Bug 46913
*** This bug has been marked as a duplicate of bug 46230 ***