[Libreoffice] [PATCH] fdo#42286, do not shrink the selected area (2)

Eike Rathke erack at redhat.com
Mon Dec 5 08:06:28 PST 2011

Hi Pierre-André,

On Sunday, 2011-12-04 22:25:51 +0100, Pierre-André Jacquod wrote:

> The first one is my favorite:
> 0001-fdo42286-strict-use-of-GetDataArea-and-strict-extens.patch
> it extends the area down. It takes into account the cells strictly
> below the already selected area. It never shrinks / shortens the
> selected area. This is the one that implement in my opinion the best
> the behaviour of adding data below already active area.
> The second one:
> 0001-fdo42286-extend-down-but-also-shrink-if-cells-are-em.patch
> has the same logic, except it allows to shrink the area, if cells
> are emptied. This the filter is allowed to extend, it could be seen
> as logic that it is also allowed to shrink.

For consistency it makes sense to also shrink the area, as
re-initializing the filter area with only one cell or one row selected
would produce the same result (plus additional columns). Also, if the
area was never shrunk and later data added in that area but not part of
the actual data area (not contiguous area) that data would be
erroneously included. Please go ahead with this one.

Please check that a defined data base range did not change behavior with
your previous changes.

Regarding variable names, it may be better to stick with naming
conventions of already existing code, i.e. it should be bShrink and
bNeedExtend, makes the code easier to read. Thanks.

> The last one:
> 0001-fdo42286-extend-down-even-if-last-row-empty-but-a-co.patch
> extend down, but also if data is added to the first cell bellow. so
> if you have something like (o means empty cell, x cell with data),
> initial filter only on B2:D3
> ooooo
> oXXXo
> oXXXo
> ooooX
> and add the last X below right, the the last line will be included
> in the area and shown with "empty cells" selection. I do not like
> this, since it suddenly take into account a column which was not
> part of the initial filtered area.

Mainly because it doesn't fulfill the contiguous data area aspects, for
which at least E3 or D4 would also have to contain data.


LibreOffice Calc developer. Number formatter stricken i18n transpositionizer.
GnuPG key 0x293C05FD : 997A 4C60 CE41 0149 0DB3  9E96 2F1A D073 293C 05FD
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <http://lists.freedesktop.org/archives/libreoffice/attachments/20111205/2083da23/attachment.pgp>

More information about the LibreOffice mailing list