Problem description: When you have some column of data, all with a header except for the last one, when ordering the option "selection includes headers" is off by default. You can turn it on, and then you will be able to select the ordering criteria based on the header names instead of column lettering (this is correct). However, the resulting order moves the first line containing header as if it were a normal data line to be ordered (this is incorrect, since you specified that data had headers used to identify columns) Steps to reproduce: 1. fill some coloums with any numeric data, and put some text description in the first row above these columns, except for the last columns on the right: for this, leave the header cell empty. 2. select the whole set of data, headers included, and go to the "data>sort" menu command (I am not using the english version, so the exact command names may not correspond to the actual one). In the first page, where you set the ordering criteria, the choices are "column A" etc. 3. switch to the second page of the sorting dialog, and tick the option "data contain headers in the first row". 4. now go back to first page, and you can correctly choose among the various headers, or the "column XX" for the last column that has no header. Choose for example the first column header as sorting criteria. 5. the result is incorrect in that the first row containing headers was ordered together with the data rows, while it should have been excluded from the sorting, staying on top in any case. This happens (correctly) when all header cells are not empty. 6. the same error takes place if the empty header is in another column (not the last one), or even if there is a numeric data in one of the headers. I think this did not happen in older releases, but I can't say in which release it started Expected behavior: when the option for the first row containing headers is active, any sorting operation should leave the first row on top regardless of the fact that some header cells maybe empty of may have numerical content Platform (if different from the browser): Browser: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:15.0) Gecko/20100101 Firefox/15.0.1
Unfortunately some further fiddling showed that the calc sorting function is now quite messy. So the opposite problem is also happening: if you select for ordering some data including text data in the first row, the sort command will by default activate the "data contain headers in the firs row" option; and that's OK. However, if you do NOT want the first row to be considered as headers, because it actually contains data just as the other rows, you deactivate that option, choose a column as sorting criteria, and then the first row is excluded from the sorting anyway (which is WRONG!). This bug can lead to MAJOR problems if you do not know it and do some sorting operations (very commonplace in a spreadsheet) without carefully examining the results. This morning for example I risked publishing messy examination results for my students because of this. Actually, if you use calc frequently recurring to sorting, the program is now quite unusable.
Unfortunately I have received no feedback on this problem, which is critical for user of calc. In the meantime I have fiddled some more with ordering functions in calc in 3.6.2 and sadly I ha to say that Horizontal ordering IS NOT WORKING at all. No way. Try writing any sequence of data in a row, select it, then choose data-ordering and select order from left to right (horizontal): NOTHING happens, nothing at all. The only way to order such data is to transpose it with copy special, order it vertically (this work, with the exception of the problems with headers already noted) and then re-trasnspose it. This very hard. I am in a difficult position with my students to whom I teach using LO. How can I tell them that such a basic operation for a spreadsheet is totally crippled? Please help. Thank you.
(In reply to comment #2) Andy, > functions in calc in 3.6.2 and sadly I ha to say that Horizontal ordering IS > NOT WORKING at all. No way. Try writing any sequence of data in a row, > select it, then choose data-ordering and select order from left to right > (horizontal): NOTHING happens, nothing at all. The only way to order such > data is to transpose it with copy special, order it vertically (this work, > with the exception of the problems with headers already noted) and then > re-trasnspose it. I can confirm the Horizontal Sort issue (I haven't tested the others you mention) in LO 3.6.3 rc1. Even activating the option "Natural Sort" does nothing. However, this might be a duplicate of a bug report already in bugzilla. Putting Kohei and Markus on CC. Alex
*** This bug has been marked as a duplicate of bug 53482 ***
Note that the horizontal sort issue is a DUP of Bug 55967 However, that bug is still present for me in 3.6.3 rc1. Alex
(In reply to comment #5) > Note that the horizontal sort issue is a DUP of Bug 55967 > > However, that bug is still present for me in 3.6.3 rc1. > > > Alex The rc1 available here : http://www.libreoffice.org/download/pre-releases/ Alex
(In reply to comment #5) > Note that the horizontal sort issue is a DUP of Bug 55967 > > However, that bug is still present for me in 3.6.3 rc1. > > > Alex The fix only went into 3.6.3.2
Alas, I am sad to note that while this bug is solved, the broken horizontal sorting function is NOT fixed in 3.6.3.2. The sort command, when applied to a row of data, still does nothing at all.