Version LibreOffice build 3.2.99.2 To reproduce : Open a OpenOffice Calc document, select a cell (or cell range) and Copy. Open LibreOffice Calc, Paste. Instead of copying cell content (value, formula...) copy/paste insert OLE object. Same result if you copy/paste from LibO to OOo. Copying both from OOo and Libo to Excel or reverse (Excel → LibO) works fine.
can you try with beta2? ( worked for me ) Or... is there perhaps particular content that you are copying that causes this ( note: I copied a mixture of plain text and some formula back and forth between OOOm9 and LibreOffice-beta2 with no problems ) e.g. in LibreOffice I a) selected a range of cell with mixed content ( text & formulas ) b) cntrl-c c) opened openoffice.org d) cntrl-v e) examined pasted content of cells ( seemed fine ) then repeated the steps above in openoffice.org pasting into libreoffice. Does this match your steps?
Created attachment 39809 [details] Copiy of the result of copy/paste
(In reply to comment #1) > can you try with beta2? It was with Beta2 > a) selected a range of cell with mixed content ( text & formulas ) > b) cntrl-c > c) opened openoffice.org > d) cntrl-v > e) examined pasted content of cells Same process. From OOo320m18 (build9502)to LibreOffice beta2, see attachment. OS: Windows Vista 32bits
urm, I tried with your document and the same openoffice version, still works for me :-( So, maybe this really is a platform specific issue ( I am using Linux ), assigning to Tor to have a look
I think I can reproduce it, yes. When I paste a selection of cells with a couple of numbers and a formula from (vanilla) OOo into LibO, I get something with an anchor "button" in the top left corner and green resize handles along the border. I guess it is an OLE object. Ditto the other way. Kohei, do you have insight what might be going on?
Note that it is not relevant whether the copy/pasted cells contain any formula or not; also just a single cell with a number gets pasted into LibreOffice as an OLE object.
Workaround added to LibreOffice: In ScViewFunc::PasteFromSystem(): If the class id of the TransferableObjectDescriptor is all-zero and the SYLK format is available on the clipboard, this seems to indicate the situation when copy-pasting from OOo Calc to LO Calc. In this case use the SYLK format data. Note that this means that formulas will not be transfered, even if the SYLK format as such does seem to support at least simple formulas. But apparently the code in OOo/LO to generate SYLK for the clipboard does not handle formulas? Nothing done for the other direction. But I guess that should be filed as a bug against OOo;) This is just a questionable workaround. The correct fix, which would take much more work to implement, would be to make OOo (and LO) offer the Biff5 and/or Biff8 formats on the clipboard. There is already code to accept these, which gets used when copy-pasting from Excel, I think. commit 27d40392c0164cd616c621b3500adac237a23ca2 Author: Tor Lillqvist <tlillqvist@novell.com> Date: Thu Nov 18 18:14:38 2010 +0200 Add workaround to avoid pasting data from OOo Calc as an OLE object Help for fdo#31077. diff --git a/sc/source/ui/view/viewfun3.cxx b/sc/source/ui/view/viewfun3.cxx index e374252..69d608d 100644 --- a/sc/source/ui/view/viewfun3.cxx +++ b/sc/source/ui/view/viewfun3.cxx @@ -680,6 +680,10 @@ void ScViewFunc::PasteFromSystem() { // If it's a Writer object, insert RTF instead of OLE + // Else, if the class id is all-zero, and SYLK is available, + // it probably is spreadsheet cells that have been put + // on the clipboard by OOo, so use the SYLK. (fdo#31077) + BOOL bDoRtf = FALSE; TransferableObjectDescriptor aObjDesc; if( aDataHelper.GetTransferableObjectDescriptor( SOT_FORMATSTR_ID_OBJECTDESCRIPTOR, aObjDesc ) ) @@ -690,6 +694,9 @@ void ScViewFunc::PasteFromSystem() } if ( bDoRtf ) PasteFromSystem( FORMAT_RTF ); + else if ( aObjDesc.maClassName == SvGlobalName( 0,0,0,0,0,0,0,0,0,0,0 ) + && aDataHelper.HasFormat( SOT_FORMATSTR_ID_SYLK )) + PasteFromSystem( SOT_FORMATSTR_ID_SYLK ); else PasteFromSystem( SOT_FORMATSTR_ID_EMBED_SOURCE ); }
So, a workaround is in place, but I wouldn't call it a proper fix, so I am keeping this bug open.
*** Bug 34108 has been marked as a duplicate of this bug. ***
Hi, I was pointed to this bug from the libreoffice mailing list. We have a similar problem which might have the same origin, so I was proposed to post it here and let you decide if it's the same problem :-) We see the problem since OpenOffice 3.2 (maybe 3.1, not in 3.0) and now in libreoffice 3.3.1.2 in SuSE Linux Enterprise Desktop 11 SP1 when we copy and paste from one libreoffice spreadsheed running on the local PC to a libreoffice spreadsheed running on a remote PC. We mark some cells with the left mouse key on the local PC. When we copy with Ctrl-C and press Ctrl-V in the remote spreadsheed, the data is inserted as expected. When we insert on the remote spreadsheed with the middle mouse key (the standard linux way for copy & paste) while the cells are stilled marked (otherwise nothing would be pasted), we get an OLE object. Copy&Paste with left+middle mouse keys works fine within the same or between two spreadsheets when both are running on the local PC or both on the remote PC. Thus, only copying+pasting between two spreadsheets on two different PCs (both could be on different remote PCs, too) and only when pasting with the middle mouse key, the data is pasted as OLE object. About your workaround (maybe it would help us, too), is it applied in some release of libreoffice so that we can easily test it? cu, Frank
The code in question is in place in the libreoffice-3-3 branch. As far as I can see, it should be in the 3.3.1.2 you have, too. But as I said, it is just a questionable workaround, and was it was written for the specific case of copy-pasteing on Windows from OOo to LibreOffice, it likely has no relevance for your case. Please file a separate bug, but do mention this bug too in that bug report.
Thanks, Tor, I opened a new bug (#38139).
Assigning this bug back to the list so that people don't think I would be actively working on fixing this properly and cross-platform (as I think is required).
[This is an automated message.] This bug was filed before the changes to Bugzilla on 2011-10-16. Thus it started right out as NEW without ever being explicitly confirmed. The bug is changed to state NEEDINFO for this reason. To move this bug from NEEDINFO back to NEW please check if the bug still persists with the 3.5.0 beta1 or beta2 prereleases. Details on how to test the 3.5.0 beta1 can be found at: http://wiki.documentfoundation.org/QA/BugHunting_Session_3.5.0.-1 more detail on this bulk operation: http://nabble.documentfoundation.org/RFC-Operation-Spamzilla-tp3607474p3607474.html
in LibreOffice 3.5.0 still reproducible?
This is a Calc bug, therefore modified the 'Component' field accordingly. Hint: this bug is still open by the reasons mentioned in comment #8. But I can't tell if the reason mentioned in comment #8 is still true. Therefore: @Tor Lillqvist: Could you please have a quick look at this bug report and check * if the reason for keeping this bug open you mentioned in comment #8 is still true (the bug is still not fixed properly, we have just a workaround) -- then please set the status of this bug again to NEW (or whatever you thing is appropriate), OR * if the bug has been really fixed in between -- then please close this bug report. Thank you very much! I am just trying to sort out outdated bug reports, in order to make it easier to see the really important bugs ...
Kohei, do you have any idea? Does LO offer Biff5 or Biff8 on the clipboard nowadays? (Assuming that is the proper fix, as I thought in comment #7.)
(In reply to comment #17) > Kohei, do you have any idea? Does LO offer Biff5 or Biff8 on the clipboard > nowadays? Nope, it still does not. But in theory we could provide Biff8 to the clipboard with some effort, though that won't help pasting from OOo to us (unless OOo does the same modification in their clipboard code). > (Assuming that is the proper fix, as I thought in comment #7.) Yes, that's the proper fix. That would also solve another issue (of pasting from Calc to Excel).
Dear bug submitter! Due to the fact, that there are a lot of NEEDINFO bugs with no answer within the last six months, we close all of these bugs. To keep this message short, more infos are available @ https://wiki.documentfoundation.org/QA/NeedinfoClosure#Statement Thanks for understanding and hopefully updating your bug, so that everything is prepared for developers to fix your problem. Yours! Florian
The error still exists. Mark range including formulas in Apache OpenOffice. Ctrl-C Goto LibreOffice Ctrl-V oder use Edit>Paste Special or use drop-down list from Paste icon. No format gives you the original formulas like a copy from one sheet to another. It is a pity that LibreOffice can paste such data from Excel but not from a related project.
Using OO.org 3.2 formulars are not working any more (Tested with LO 3.6)
(In reply to comment #24) > Using OO.org 3.2 formulars are not working any more (Tested with LO 3.6) Sorry, could you please explain this? I don’t understand this sentence, probably there is a typo somewhere (a word too much or a word missing).
Comment #24 doesn't seem to match the scenario described in the initial comment; if I understand correctly the problem occurs even for only numbers, no formulas involved. So a separate bug report is needed for what comment #24 describes.
Oka! I try to explain A1,A2,A3 1,2,=A1+A2 (3) Imported from OO.org A3 shows the number 3, not the formula
And the reason is the same as in the initial report: A wrong clipboard format is used. The clipboard format Calc8 is not detected.
And "import" means? This bug is about copy-pasting from OOo to LO. Not importing a file.
Yes, pasted
Please read this message in its entirety before responding. Your bug was confirmed at least 1 year ago and has not had any activity on it for over a year. Your bug is still set to NEW which means that it is open and confirmed. It would be nice to have the bug confirmed on a newer version than the version reported in the original report to know that the bug is still present -- sometimes a bug is inadvertently fixed over time and just never closed. If you have time please do the following: 1) Test to see if the bug is still present on a currently supported version of LibreOffice (preferably 4.2 or newer). 2) If it is present please leave a comment telling us what version of LibreOffice and your operating system. 3) If it is NOT present please set the bug to RESOLVED-WORKSFORME and leave a short comment telling us your version and Operating System Please DO NOT 1) Update the version field 2) Reply via email (please reply directly on the bug tracker) 3) Set the bug to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + LibreOffice is powered by a team of volunteers, every bug is confirmed (triaged) by human beings who mostly give their time for free. We invite you to join our triaging by checking out this link: https://wiki.documentfoundation.org/QA/BugTriage There are also other ways to get involved including with marketing, UX, documentation, and of course developing - http://www.libreoffice.org/get-help/mailing-lists/. Lastly, good bug reports help tremendously in making the process go smoother, please always provide reproducible steps (even if it seems easy) and attach any and all relevant material
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.