<html>
<head>
<base href="https://bugs.documentfoundation.org/">
</head>
<body><span class="vcard"><a class="email" href="mailto:newbie-02@gmx.de" title="b. <newbie-02@gmx.de>"> <span class="fn">b.</span></a>
</span> changed
<a class="bz_bug_link
bz_status_NEW "
title="NEW - Calc - Standard Filter produces wrong display (Selection range is automatically expanded)"
href="https://bugs.documentfoundation.org/show_bug.cgi?id=35923">bug 35923</a>
<br>
<table border="1" cellspacing="0" cellpadding="8">
<tr>
<th>What</th>
<th>Removed</th>
<th>Added</th>
</tr>
<tr>
<td style="text-align:right;">CC</td>
<td>
</td>
<td>newbie-02@gmx.de
</td>
</tr></table>
<p>
<div>
<b><a class="bz_bug_link
bz_status_NEW "
title="NEW - Calc - Standard Filter produces wrong display (Selection range is automatically expanded)"
href="https://bugs.documentfoundation.org/show_bug.cgi?id=35923#c23">Comment # 23</a>
on <a class="bz_bug_link
bz_status_NEW "
title="NEW - Calc - Standard Filter produces wrong display (Selection range is automatically expanded)"
href="https://bugs.documentfoundation.org/show_bug.cgi?id=35923">bug 35923</a>
from <span class="vcard"><a class="email" href="mailto:newbie-02@gmx.de" title="b. <newbie-02@gmx.de>"> <span class="fn">b.</span></a>
</span></b>
<pre>for the Bug Hunting Session 7.0.0.0.a1+:
bug still as described by the OP,
It's an ambiguous decision: a normal - inexperienced - user would of course
like automatic range selection and newly added data to be filtered or sorted as
well, but the same - inexperienced - user would not like his column-totals or
footnotes to be filtered or sorted.
It is difficult for a more algorithmic than intelligent program to meet both
requirements.
I think there have been long discussions and lonely decisions about this ...
Are my observations correct:
sort considers in the following order:
1. the current selection in the sheet, if it is larger than one cell,
2. an "__Anonymous_Sheet_DB__0" - automatic database area - if it is left over
from the previous creation of a filter and the focus is in this area, if this
area is divided by empty columns or rows only contiguous areas are taken? (the
'anonymous' areas are never deleted but only redefined once they are on a
sheet?)
3. a defined 'data range' if the focus is in it,
3a. overlapping database areas are evaluated a little bit strange, with focus
in the first (older or upper or 'left') area this is selected, with focus in
the overlapping area also, with focus in the second (newer, deeper or
'righter') database area both areas are combined?
4. otherwise sort itself defines a rectangular area bordered by empty cells,
and if this includes only the one selected cell ...
5. just sorts this one cell,
6. sort has an option to 'sort by row' - horizontally - and then re-arranges
columns instead of rows,
whereas filters - all filters? -
1. simply always according to sort-4. define a filter range by themself and
ignore all specifications from the user?
2. have no 'horizontal' option and therefore should neither evaluate tags
'table:orientation="column"' from the files nor handle parameters 'bByRow' or
'bByColumn' in the evaluations for the filtering (UI and basic / macros) or let
them influence the field assignments?
- puhhh that was long, is that described somewhere as 'target behaviour'? -
my approach would be:
- sort is much more user friendly than the filters,
- sort should not consider the automatic data area, which is not intuitive or
manageable for the user,
and filter should either:
- behave as sort, and respect the user's specifications,
or:
- have a query in the filter definition: 'which area do you want to edit?
"defined" B3:F165, or "automatic" B2:H182'
but there may be more ideas, and they may become difficult once excel
compatibility is taken into account?</pre>
</div>
</p>
<hr>
<span>You are receiving this mail because:</span>
<ul>
<li>You are the assignee for the bug.</li>
</ul>
</body>
</html>