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?