Problem description: In certain cases, the "header-identifying heuristic" misbehaves, thus glitching the sort. This happens under the following conditions: * not all header cells are filled out * the data is text (it worked for some combination of text and numbers, thus this constraint) Steps to reproduce: 1. Create a table, containing the following data (CSV syntax): TITLE, (empty cell) Beta1, Beta2 Zeta1, Zeta2 Alfa1, Alfa2 Delta1, Delta2 2. a) Select cells "Beta1" to "Delta2", or 2. b) select cells "TITLE" to "Delta2". 3. Sort ascending. Current behavior: In case of 2. a), the "sorted" table looks like: TITLE, (empty cell) Beta1, Beta2 Alfa1, Alfa2 Delta1, Delta2 Zeta1, Zeta2 Which is obviously wrong—the row "Alfa" should come _before_ "Beta". Apparently, Calc tried to be smart and identified the "Beta"-row to be a header; which it is not. Well, that's actually kind of cool—unfortunately, that's not what I wanted. So I figure I just have to select the header-row, too… So now to 2. b). In case of 2. b), the "sorted" table ends up looking like: Alfa1, Alfa2 Beta1, Beta2 Delta1, Delta2 TITLE, (empty cell) Zeta1, Zeta2 Which—again—is not what I wanted: Judging by the result of 2. a), it is not even what I expected. Expected behavior: The sorted table should look like: TITLE, (empty cell) Alfa1, Alfa2 Beta1, Beta2 Delta1, Delta2 Zeta1, Zeta2 Ideally, it should look like this *both times* (though I understand that the heuristic would be basically impossible to define). More realistically, the sorting should be possible to do at all. Current workaround: Fill the empty cell in the header row with dummy data and then sort—sorting works as expected. (Optionally, subsequently remove the dummy data.) Operating System: Mac OS X Version: 4.1.5.3 release
Hello na+lo-bz, With example 2a, its assuming that the Beta1 row is the column labels and with 2b, its assuming your sorting the columns. You can see this clearly if you go into the menu under Data > Sort. If you wish 2a to work how you expect, click on the options tab, and uncheck 'range contains column labels'. So in your opinion, the behaviour should be constant with both 2a and 2b?
Hello Jay, thanks for your comment. I imagined there was a way to make it do the correct thing! And yes, in my opinion – even though I do understand the logic behind it – the behaviour still actually should be the same for 2a and 2b: I don't believe that a "normal user" would see through the mechanism. Thing is, it's strange that two different things happen when I do the exactly same thing (determinism and such ;-) ). (Of course, the error is exacerbated in this particular case due to the fact that neither result is the desired one.) Nicola
So a bit of my input here. What is happening is that if a value is empty then it treats it like the check mark in "Range Contains Column Headers" as non existent and thus there are no headers. If you put in TITLE2 in B1 (currently you have this as empty) then select TITLE to delta2 and do the sort, it works as expected. So here is the proposed solution: We just trust the user to select what they want, and if "Range Contains Column Headers" is selected, even if all headers are blank, we treat these like headers and they are not sorted with the sort. So I am marking this as: New Enhancement Request - works as expected but for functionality purposes this seems like a good idea Low - relatively straight forward work around, don't select the headers and uncheck the "Range Contains Headers" button.
Joel: Your suggestion seems reasonable and makes sense. Thanks for your input! Nicola
Migrating Whiteboard tags to Keywords: (needsDevEval) [NinjaEdit]
My guess is that this is after all a duplicate of bug 63416. Closing as such. Apologies if I'm mistaken. Then please reopen and clearly explain. Thanks - Cor *** This bug has been marked as a duplicate of bug 63416 ***