When creating a XLS workbook with more than two worksheets, the worksheets three and on will not hold their position when saved and re-opened. I attached an Excel workbook containing four worksheets. Please scoll each of it to a certain position, enter any text or information you like at there and save it again (File -> Save). After re-opening, the first two worksheets have preserved their position while the last two will be presented scrolled to the very top. As LibreOffice 3.3.3 did not show this behaviour, I think this is a bug introduced somewhere inbetween 3.3.3 and 3.5.4 (did not check on any other version, yet). Can someone please confirm this behaviour ?
Created attachment 63014 [details] Shows wrong scrolling / positioning behavior in LibO 3.5.4 Calc with Excel workbooks containing more than 2 worksheets
Checked with: LO 3.5.4.2 Build ID: own W7 debug build Windows 7 Professional SP1 64 bit Could not reproduce.
I was able to reproduce the behavior on my laptop at work today: When opening the attached XLS file with Microsoft Excel 2007, I get all four sheets positioned correctly. If I open it using LibreOffice 3.5.4 Calc, only the first two sheets appear at the correct position while Worksheet 3 and Worksheet 4 are always shown positioned at the very top (cell A1). Laptop System Specs: Dell Vostro 1700 Windows Vista x86 SP2 MS Office 2007 LibreOffice 3.5.4.2 (clean install; no version of LibreOffice or OpenOffice was ever installed on this machine before) Can somebody please try download the file attached in LibreOffice 3.5.4 on another "non-clean" Windows (= already used for some weeks / month) installation and check for the cursor / scrollbar position in all four worksheets ? If it really can't be reproduced by anybody else, I wonder what causes my two very different installations / machines to show this strange scrolling behavior in workbooks with more than two worksheets...
I too have come across this bug with my own spreadsheets. Using Archlinux up to date on 30-07-12 with Libreoffice 3.5.5.3, Worksheets 3, 4, 5, and onwards do not return to the last position, the selected cell always goes to A1. Using the reporters attached workbook also does not work correctly. When using Debian Wheezy and Libreoffice 3.4.3 the workbooks work correctly on the worksheets. I also noticed this on some previous versions to 3.5.5.3 with Archlinux, but did not keep the version information.
Now also checked with: LO 3.5.5.3 Build ID: 7122e39-92ed229-498d286-15e43b4-d70da21 Windows 7 Professional 64 bit Issue is reproducible with the above attached workbook. Worksheet 2 and 3 return to A1. With Excel 2010 on the same machine the workbook works as expected.
(In reply to comment #3) > Checked with: > LO 3.5.4.2 > Build ID: own W7 debug build > Windows 7 Professional SP1 64 bit > > Could not reproduce. Rechecked with: LO 3.5.5.3 Build ID: own W7 debug build Windows 7 Professional SP1 64 bit Seems there is a pattern in this. Saving cursor position depends on which workbook is active when saved as. We have following combinations: - w1 active - w3, w4 at A1 - w2 active - w4 at A1 - w3 active - all good - w4 active - all good
I now have Libreoffice updated to 3.6.2.1, on Archlinux, and this still shows the same behaviour.
Just to say that i'm too am having this. For me it's a major problem, since my main sheet has more than 3k lines and it's moving to the top everytime the last 4 tabs (preserving the 2 first), so i can't use this version of LO and had to install 3.4.6 instead (works well). I tried in ubuntu 12.10 and mint14. It does NOT happen if the sheet is in ODS format, but for my big sheet i still prefer the XLS bc it's around 80%-100% faster to open it and around 25% to save than ODS. Thanks all for the hard work!
Created attachment 78166 [details] test file for Calc bug 51066, comment 10 This bug is still present in LibreOffice 4.0.2.2. In addition to scroll position, frozen panes are also lost in sheets >2. Attached file "calc_fdo51066c10.xls" was created in Excel 2003 on Windows 8. It has 6 identical sheets: 200 rows, first column/row are frozen, row 200 is scrolled up to be second from top. When the file is opened in LibreOffice, only the first two sheets have frozen panes and correct scroll position. Apache OpenOffice 3.4.1 and earlier is not affected.
*** This bug has been marked as a duplicate of bug 61060 ***
Sorry again..not duplicate. Still reproducible, same behavior as comment 7 Tested on LO 4.0.4.1 (Win7 32bit)
rechanging Version : 3.5.4 release -> oldest version known Platform : All -> Windows & Linux 32/64bit
This is still not fixed in LibreOffice 4.1.4. Apache OpenOffice 4.0.1 is not affected.
Same problem, .xls with 7 worksheets. Only 2 sheets save cursor location. Version: 4.1.4.2 Build ID: 410m0(Build:2) on openSuse 13.1
Now using LO 4.1.5.3 on Win7 64 bit and this bug appears to be fixed, it works okay with the Wrong_scrolling_demo.xls. Not tested LO 4.1.5.3 on a Linux distribution and also have not yet tested LO 4.2.x.x
This is fixed in LibreOffice 4.2.1.1, but only for individual XLS files. Tested with winPenPack X-LibreOffice 4.2.1 [rev17], Windows 8. When individual XLS files are opened, the scroll position and frozen panes are set correctly in all sheets and saved correctly after saving files as ODS. Unfortunately, the bug is still present when doing batch conversion from XLS to ODS. How to reproduce: 1) Download the two attached XLS files into a separate folder. 2) New Calc spreadsheet, File -> Wizards -> Document Converter -> check "Excel documents", specify folder with downloaded files, do conversion. 3) Open .ods files -- none of the sheets have scroll positions or frozen panes set, even the first two sheets.
** Please read this message in its entirety before responding ** To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present on a currently supported version of LibreOffice (5.0.4 or later) https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the version of LibreOffice and your operating system, and any changes you see in the bug behavior the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a short comment that includes your version of LibreOffice and Operating System Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) http://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to "inherited from OOo"; 4b. If the bug was not present in 3.3 - add "regression" to keyword Feel free to come ask questions or to say hello in our QA chat: http://webchat.freenode.net/?channels=libreoffice-qa Thank you for your help! -- The LibreOffice QA Team This NEW Message was generated on: 2015-12-20
I tested for this issue using LibreOffice Calc 5.0.3.2 on Windows 8.1 Pro x64 and was unable to reproduce it using both attachments (XLS files).