Under some conditions, AutoFilter pops up a yes/no dialog with the following text: The range does not contain column headers. Do you want the first line to be used as column header? The action result is the same whatever the use decides on this dialog. How to reproduce (from new empty sheet): - input "1" in A1 - input "2" in A2 - click on A1 - trigger AutoFilter action (Data -> Filter... -> AutoFilter) Here, you should see mentioned dialog. - Click "No" - First row is used as a filter Extra details on final state: only row with value "2" is visible below filter cell, "1" and "2" values are available for filtering when expanting filter's dropdown menu. Note: this may be related to #63416, but the relation is unsure to me, so I opened this bug. Regards, Vincent Pelletier
I don't understand the problem here. Do you want the user interface to be different somehow?
The issue is: "The action result is the same whatever the use[r] decides on this dialog." (sorry for the typo in original report, corrected above) So the dialog asking user to make a (Yes/No) choice, but that choice is ignored.
Just for reference, I reproduced described behaviour with 4.3.3.2 as of a recent-ish Debian sid package (1:4.3.3~rc2-1).
For me, there is no problem. The action result is totally different: if I select "Yes" for the column header question, opening the dropdown only shows "2". Does the dropdown being in the first cell bother you? Or does "1" actually become invisible and you only see the dropdown triangle?
This issue is most probably the same problem as bug 63416. But for me it is not yet clear why sometimes the "Do you want the first line to be used as column header?" dialog appears. Thus, this behaviour merits at the moment its own bug report.
The dialog doesn't lock the first row if I click YES. Check with numbers. What info is needed?
Sorry for only noticing your response now. (In reply to Beluga from comment #4) > For me, there is no problem. The action result is totally different: if I > select "Yes" for the column header question, opening the dropdown only shows > "2". It looks like I misunderstood the dialog intent as items available in dropdown are indeed different depending on clicked dialog button. > Does the dropdown being in the first cell bother you? Exactly: I expected one of the button (likely the "no" button, which I read as "do not alter the first row") to cause a new row to be inserted before the first row, and filters to be added in that new row. > Or does "1" actually become invisible and you only see the dropdown triangle? I confirm, "1" is correctly visible next tot he dropdown triangle.
Thanks for the reply, Vincent! I will close this as INVALID then.
This action doesn't lock first row. Or it is not related to this bug? Steps to reproduce Fill A1:F7 with random numbers Highlight this arrow Click autofilter, use the first line as a header Click sort in the one of dropdown dialog The fisrt line is now somewhee in the middle!
(In reply to Yan Pashkovsky from comment #9) > This action doesn't lock first row. Or it is not related to this bug? > > Steps to reproduce > Fill A1:F7 with random numbers > Highlight this arrow > Click autofilter, use the first line as a header > Click sort in the one of dropdown dialog > The fisrt line is now somewhee in the middle! Please open a new report for this.
(In reply to comment #10) > Please open a new report for this. This is not necessary. This problem is already covered in bug 63416. The current bug 65178 is a part of bug 63416. The autofilter sorting code ignores the decision of the user. I've submitted a patch for review: https://gerrit.libreoffice.org/#/c/15277/ This patch addresses exactly the current bug report. However, it does not solve the full bug 63416 which must also handle data rows without header row (only data rows). Then the autofilter buttons should not move, but stay at the first row, even if the data changes at the first row. *** This bug has been marked as a duplicate of bug 63416 ***
(In reply to Beluga from comment #8) > Thanks for the reply, Vincent! I will close this as INVALID then. FWIW, I noticed that, after clicking "no" in the dialog, if I uncheck "1" in the dropdown, the filter row itself disappears (actually, it seems it gets resized to 0-height) - thus hiding the dropdown hence preventing me from checking it back. Is this expected ? Is it already covered in 63416 (at a glance, it doesn't seem to be) ?
(In reply to Vincent Pelletier from comment #12) > (In reply to Beluga from comment #8) > > Thanks for the reply, Vincent! I will close this as INVALID then. > > FWIW, I noticed that, after clicking "no" in the dialog, if I uncheck "1" in > the dropdown, the filter row itself disappears (actually, it seems it gets > resized to 0-height) - thus hiding the dropdown hence preventing me from > checking it back. > > Is this expected ? > Is it already covered in 63416 (at a glance, it doesn't seem to be) ? I tried this and I can drag the row back to normal height from the upper right corner (between 1 and A, mouse pointer turns to a double-arrow).
(In reply to Beluga from comment #13) > I tried this and I can drag the row back to normal height from the upper > right corner (between 1 and A, mouse pointer turns to a double-arrow). It is indeed possible to resize the row - this is how I discovered the resized-to-0-height. My interrogation is just that I feel the overall behaviour is surprising, although not fundamentally wrong (no data is lost & there is no crash): is it really intended ? To me, the overall behaviour feels surprising enough that I think the "no" dialog button effects are too difficult to understand to be really useful. I think not having this dialog would have made me find the correct solution (for my use-case) faster: - insert row above, with some column titles so that it's picked up by autofilter (and I see this behaviour is being improved in 63416) - autofilter (click "yes" in dialog if dialog is presented) - done That's just my 2 cents, I rarely use spreadsheets at all (and only OOo/LibO), so I may just not know what behaviour to expect.