Created attachment 52316 [details] Presentation with screenshots Steps to reproduce with "LibreOffice 3.4.3 - WIN7 Home Premium (64bit) German UI [OOO340m1 (Build:302)]": 1. Open spreadsheet document with named data range containing Column labels, Frozen Window 2. Click Autofilter Button in column header 3. Select Autofilter As expected filter dialog appears unexpectedly Autofilter puldowwn buttons disappear in column headers This problem is not 100% reproducible, related to particular documents
Created attachment 52318 [details] Sample document With mysample.ods the filter problem is reproducible for me
Also [Reproducible] with Server installation of Master "LibO-dev 3.5.0 – WIN7 Home Premium (64bit) English UI [(Build ID: d3d1481-3f8994a-2ba0a9f)]" (110909) Might be related to "Bug 30925 - Remove filter does not work for Autofilter"
Hi, Reproductible with LibreOffice 3.4.3 under Windows Vista. Datarange Aktuell is defined as $Endgueltig.$A$1:$AD$122 with option "Contains column labels" checked. Columns Y to AD are empties (without column labels). If i change the datarange to $Endgueltig.$A$1:$X$122, i cannot reproduce. Also, if i add labels where missing (Y1 to AD1), bug isn't reproductible. Hope this helps.
Created attachment 52332 [details] screenshot of datarange used by autofilter I also noticed that range use by filter not meet range defined in Data > Define range. Filter use the table delimited by empty row and empty column (highlighted by key Ctrl+*), this range is called _Anonymous_Sheet_DB_ instead of Datarange defined by user. See attached screenshot.
Created attachment 52340 [details] New simple test document GerardF's gave me some new ideas for additional tests. The reason for the problem seems to be the filter data range with empty column label cell for the last column. At least typing a single letter into that cell solves the problem for me in several affected spreadsheets I tested. Steps to reproduce: 1. open attached simple spreadsheet "new_sample1.ods" 2. Select / mark A1:M40 3. Menu 'Data -> Define Dange - Name = "filterarea" -> More -> check "Contains Cloumn Labels" if necessary' <OK> DB range name has been created 4. Save as "new_sample2.ods" 5. Menu 'Data -> Filter -> Autofilter' Filter buttons appear 6. For column D click filter button 7. Select 'Standard filter' Unexpecedly Autofilter buttons disappear Clicking <More> in dialog shows new range 'A1:I38' with name "_Anonymous..." 8. Quit without saving 10. Open "new_sample2.ods" 11. Menu 'Data -> Filter -> Autofilter' Filter buttons appear 12. type an "x" into 'M1' and <Enter> 13. For column D click filter button 14. Select 'Standard filter' Now the Autofilter buttons remain, everything will work as expected. With th "x" in 'L1' instead of 'M1' the problem remains @GerardF: Very very good catch!
My observations were not exact, a letter anywhere in the last column and filter range is enough to avoid the problem. OOo 3.1.1 behaves the same way like LibO. OOo 3.4 forces use of "__Anonymous_Sheet_DB__0" more consequently and seems not to suffer from the problem. I can't tell whether other OS will be affected. CONFIRMED due to Comments 3,4 @sumuthu: Please feel free to reassign (or reset Assignee to default) if it’s not your area or if provided information is not sufficient. Please set Status to ASSIGNED if you accept this Bug. - Reported with Bug Submission Assistant -
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
This is a duplicate of bug 63416. Header recognition is currently quite odd: a header row is recognized in autofilter only if all column headers are text, i.e. no empty cells and no numbers. Otherwise, the header row and autofilter buttons will move. Thus, this bug is duplicate. *** This bug has been marked as a duplicate of bug 63416 ***
Maybe it's not a duplicate, but related. Bug 63416 is about sorting. The current issue seems to be about filtering.
** 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.5 or 5.1.2 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 If 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: 2016-04-16
I do not reproduce this issue under linux with the the most recent versions: Version: 5.3.0.0.alpha1 Build ID: f4ca1573fcf445164c068c1046ab5d084e1b005f CPU Threads: 4; OS Version: Linux 4.4; UI Render: default; VCL: gtk2; Locale: zh-CN (zh_CN.UTF-8); Calc: group Since this bug is described as for Windows, but there is no response for additional testing information, I set this as RESOLVED INVALID.