Created attachment 180669 [details] The document where i found the bug In the calc document that i attached, when i sort the A2:B5 range ascending, it doesnt get sorted. But if i first sort it descending and then ascending, it does. The same happens if i copy the A2:B5 range to any cell, for example E1.
There's definitely something weird here. If you replace the contents in cells B2:B5 (the telephone numbers) by something else (e.g. 1, 2, 3 and 4), then sorting works as expected. For some reason, these numbers are messing with sorting.
Some interim results with Server Installation of Version: 7.4.0.0.alpha0+ (x64) Build ID b871abad383583f02eb49c7e49aeae01f6941072 CPU threads: 12; OS: Windows 10.0 Build 19044; UI render: Skia/Raster; VCL: win Locale: de-DE (de_DE); UI: de-DE | Calc: CL | Auto Colibre Theme | Newly created l User Profile: a) Not related ro reporter's document, I also can reproduce that in newly created documents b) some preconditions are required that the effect appears b1) The block to be sorted starts in row 2 be) First row of the block is row 1 b2) column 1 of the block only contains not-numeric strings (means: no numbers)
c) part of the effect is that contents of 'Sort key 1 - Column 1' contents does not show a table column heading, but contens of first row of the contens block (in reporter's sample document: contents of cell A1)
Created attachment 180673 [details] New sample document d) some more results with new sample and Server Installation of Version: 7.4.0.0.alpha0+ (x64) Build ID b871abad383583f02eb49c7e49aeae01f6941072 CPU threads: 12; OS: Windows 10.0 Build 19044; UI render: Skia/Raster; VCL: win Locale: de-DE (de_DE); UI: en-US | Calc: CL | Auto Colibre Theme | Special devUserProfile (probably identical with LibO 7.3) see in attachment Sheet 3 I'm a little worried.
e1) already REPRODUCIBLE with Server Installation of Version: 6.0.7.3 (x64) Build-ID dc89aa7a9eabfd848af146d5086077aeed2ae4a5; CPU-Threads: 12; BS: Windows 10.0; UI-Render: GL; Gebietsschema: de-DE (de_DE); Calc: CL, Special devUserProfile e2) was still ok with Server Installation of Version: 4.0.0.3 WIN10 Build-ID 7545bee9c2a0782548772a21bc84a9dcc583b89; Special devUserProfile That's it from my side for now.
On pc Debian x86-64 with master sources updated today, I gave a try with first file, I could reproduce this. It seems ascending order considers first row of the selection as the heading (so doesn't take it into account) but descending order doesn't. Then after having used descending order, ascending order doesn't consider anymore first row as heading. If using Sort dialog, we can see that first row of selection as the heading is the default and if we let this checkbox enabled and sort by descending then ascending, it sorts as expected, by keeping first row of the selection unchanged. So I think there's just a pb with descending sort which doesn't take first of selection as heading as default + disable it.
Eike: does this patch make sense? diff --git a/sc/source/ui/view/cellsh2.cxx b/sc/source/ui/view/cellsh2.cxx index bc9dc416b1d5..a0d3fd14b0de 100644 --- a/sc/source/ui/view/cellsh2.cxx +++ b/sc/source/ui/view/cellsh2.cxx @@ -392,7 +392,7 @@ void ScCellShell::ExecuteDB( SfxRequest& rReq ) else if( nCol > aSortParam.nCol2 ) nCol = aSortParam.nCol2; - aSortParam.bHasHeader = bHasHeader; + aSortParam.bHasHeader = aSortParam.bHasHeader || bHasHeader; aSortParam.bByRow = true; aSortParam.bCaseSens = false; aSortParam.bNaturalSort = false; I mean, we got 388 bool bHasHeader = rDoc.HasColHeader( aSortParam.nCol1, aSortParam.nRow1, aSortParam.nCol2, aSortParam.nRow2, nTab ); which tries to "guess" if there's a column header but if the checkbox "Range contains column labels" is enabled, and it's the case by default, we should keep this and use the result of bHasHeader only if disabled. What do you think?
Is there any new on this?
(In reply to Julien Nabet from comment #7) > Eike: > does this patch make sense? > diff --git a/sc/source/ui/view/cellsh2.cxx b/sc/source/ui/view/cellsh2.cxx > index bc9dc416b1d5..a0d3fd14b0de 100644 > --- a/sc/source/ui/view/cellsh2.cxx > +++ b/sc/source/ui/view/cellsh2.cxx > @@ -392,7 +392,7 @@ void ScCellShell::ExecuteDB( SfxRequest& rReq ) > else if( nCol > aSortParam.nCol2 ) > nCol = aSortParam.nCol2; > > - aSortParam.bHasHeader = bHasHeader; > + aSortParam.bHasHeader = aSortParam.bHasHeader || > bHasHeader; > aSortParam.bByRow = true; > aSortParam.bCaseSens = false; > aSortParam.bNaturalSort = false; > > > I mean, we got > 388 bool bHasHeader = rDoc.HasColHeader( aSortParam.nCol1, aSortParam.nRow1, > aSortParam.nCol2, aSortParam.nRow2, nTab ); > which tries to "guess" if there's a column header but if the checkbox "Range > contains column labels" is enabled, and it's the case by default, we should > keep this and use the result of bHasHeader only if disabled. > What do you think? Is there any new on this?
Dear santo.998, 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 with the latest version of LibreOffice from https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the information from Help - About LibreOffice. If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice. 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) from https://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: https://web.libera.chat/?settings=#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug