Date: prev next · Thread: first prev next last
2011 Archives by date, by thread · List index


Hi Pierre-André,

On Sunday, 2011-11-27 20:23:33 +0100, Pierre-André Jacquod wrote:

I wouldn't say it's wrong unless I checked the original intention behind
that code when GetDataArea() is called with bIncludeOld=false, maybe
it's just the call in ExtendDataArea() that should pass true instead?

Done, you're right.
Finally, changed the call of the flags and documented the flags' meaning.
If you could cherry-pick 88611e702a18d2 for 3.4.5, would be nice.

Now you also changed bOnlyDown=false to bOnlyDown=true, which leads to
not include newly appended columns of an area. Why?


Further some tests have shown me that the behaviour
(regarding area) is not the same, depending if the filter is
activated with Data->Filter->AutoFilter or Standard filter. I fear
some parts will need to be quite overhauled.

And the difference exactly is ...?

Visually: the standard filter adapts and shows the selected area at
activation of the filter, the auto-filter does not reflect the fact
that it will take into account a wider area. This area extension
happens only when the drop-down button is activated and the list of
possible value is calculated...  and the area extended.

Probably because people want a selection within an auto-filtered area to
stay active and nevertheless filter for new values. Reselecting the
entire data area in that moment isn't a good user-experience.


Out of subject: from a user perspective, I am not convinced from te
fact that the filter is allowed to change an area that has been
user-defined. No problem to auto-extend an area if auto-determined.
But if a user takes the time to do the area, this should be "holly".
But this point belongs to the user-interface list I guess...

Grounded speculation: if user adds a column or row immediately adjacent
to a data area it is usually related to the already existing data and
she wants that to be included, maybe even doesn't know that earlier the
filter was setup using a selection.

  Eike

-- 
LibreOffice Calc developer. Number formatter stricken i18n transpositionizer.
GnuPG key 0x293C05FD : 997A 4C60 CE41 0149 0DB3  9E96 2F1A D073 293C 05FD

Attachment: pgpSTgOS5CZAL.pgp
Description: PGP signature


Context


Privacy Policy | Impressum (Legal Info) | Copyright information: Unless otherwise specified, all text and images on this website are licensed under the Creative Commons Attribution-Share Alike 3.0 License. This does not include the source code of LibreOffice, which is licensed under the Mozilla Public License (MPLv2). "LibreOffice" and "The Document Foundation" are registered trademarks of their corresponding registered owners or are in actual use as trademarks in one or more countries. Their respective logos and icons are also subject to international copyright laws. Use thereof is explained in our trademark policy.