Issue 85305

Summary: Dynamically grow a filtered range for autofilter, standard filter, and advanced filter
Product: Calc Reporter: kyoshida
Component: codeAssignee: kla <thomas.klarhoefer>
Status: CLOSED FIXED QA Contact: issues@sc <issues>
Severity: Trivial    
Priority: P3 CC: acelists, cmoulin, cno, frank.loehmann, hdu, issues, kamataki, kpalagin, manens, masaya.k, mike.hall, moixa, movie_cat, nbenitezl, nesshof, pagalmes.lists, raal, rail_ooo, strob08, vitriol_vitriol
Version: 680m241Keywords: ms_interoperability
Target Milestone: 3.4.0   
Hardware: All   
OS: All   
Issue Type: PATCH Latest Confirmation in: ---
Developer Difficulty: ---
Description Flags
file that stores out-of-date filtered range
proposed patch
revised patch none

Description kyoshida 2008-01-16 17:36:46 UTC
It would be desirable to have Calc dynamically resize a filtered range when new
data rows are appended to the existing data table.  Excel behaves this way, and
it's very intuitive.

This also helps interoperability with Excel, since the filtered ranges stored in
Excel file contain the original ranges before resizing, which Calc imports and
applies "as is" thus causes problem.

I will attach an Excel file to demonstrate the problem.
Comment 1 kyoshida 2008-01-16 17:39:37 UTC
Created attachment 50914 [details]
file that stores out-of-date filtered range
Comment 2 kyoshida 2008-01-16 17:46:07 UTC
The attached file demonstrates the oddity when importing into Calc.  Though the
data table appears to have three data rows, none of them show up in the
autofilter popup.
Comment 3 kyoshida 2008-01-16 17:49:04 UTC
Created attachment 50915 [details]
proposed patch
Comment 4 kyoshida 2008-01-16 17:51:23 UTC
The attached patch dynamically resizes a filtered range when new data rows are
appended below the table.  It also marks some of ScDocument's methods const for
Comment 5 kyoshida 2008-01-17 14:03:48 UTC
setting target to 3.0.
Comment 6 kyoshida 2008-01-29 04:13:45 UTC
@nn: can you take a look at this patch when you have a chance?  Thanks.
Comment 7 kpalagin 2008-02-03 14:25:52 UTC
Seems to be great feature.
Comment 8 pagalmes.lists 2008-02-20 09:31:53 UTC
Thanks for the patch, that would enhance greatly the user experience. 
Comment 9 kyoshida 2008-03-05 17:28:20 UTC
Created attachment 51917 [details]
revised patch
Comment 10 kyoshida 2008-03-05 17:31:57 UTC
I've slightly changed the implementation.  The new implementation does not
modify the original database range; instead, it tracks the dynamic end-row
position separately, and use it only for filtering operations.  This way there
is less surprises since it will not alter named database ranges behind the scenes.
Comment 11 kyoshida 2008-03-15 03:02:07 UTC
setting MS interop keyword.
Comment 12 pagalmes.lists 2008-04-09 12:56:53 UTC
Is there a milestone where we can test this new feature?
Comment 13 kyoshida 2008-05-08 05:08:09 UTC
@pagalmes: this patch is in ooo-build, so you can try one of ooo-build variants
to test it out.  Or you can just get one from here [ ].
Comment 14 niklas.nebel 2008-06-25 10:45:54 UTC
Undo doesn't work. But more fundamentally, such special-case handling always
causes inconsistencies. A database range would have two different end rows, one
used for filtering, one for the other operations. For unnamed database ranges,
similar (but not the same) logic is already in ScDocShell::GetDBData. If
anything, that should be extended.
Comment 15 kyoshida 2008-06-25 15:10:40 UTC
@nn: the undo stuff should be fairly easy to fix.  I'll also look into
ScDocShell::GetDBData too although there was a reason why I did it the way I did
(I forget now since it was a long time ago.)
Comment 16 kpalagin 2008-06-27 11:19:51 UTC
Such handling is what drives me nuts in this project - developer invests 
effort, creates a patch, provides it and 6 month later patch gets reviewed and 
rejected just before code freeze, leaving no time to fix. This happens 
consistently over the years leading me to beleive that PLs are not interested 
in project development.
Hopefully other distributions will do better than Sun.
Comment 17 kpalagin 2008-12-05 13:00:29 UTC
have you had a chance to update your patch after Niklas revewed it?

K. Palagin.
Comment 18 kyoshida 2008-12-05 13:43:53 UTC
No, but I remember the reason why I did it like that.  Because the dynamic last
row position is recalculated on the spot before each autofilter/standard
filter/advanced filter dialog launch, there is no need to make it
undo/redo-able.  So from my POV there is nothing to fix here.
Comment 19 kpalagin 2008-12-05 14:28:18 UTC
What do you think about having single database range for both filtering and 
everything else? 
Comment 20 kyoshida 2008-12-05 14:52:36 UTC
Only the filtering actions make use of dynamic row positions.  For everything
else, the original database range is used.  I personally think it's fine the way
it works like that.  I don't know if this answers your question or I'm
mis-interpreting it... ;-)
Comment 21 camillem 2009-07-01 10:09:41 UTC
Any news about the possible integration of Kohei's patch?
Comment 22 mike_hall 2009-08-28 11:37:27 UTC
Not having an inbuilt 'automatic' spreadsheet range extended when more data is
added is very non-intuitive. This is something that naive users would find very
difficult to understand and debug. I found the reason for only by accident.
Suggest that the target is changed to 3.2 or if that isn't possible, then 3.2.1
or 3.3. 
Comment 23 cno 2009-09-02 18:23:55 UTC
Isn't issue 59229 about the same problem?
Comment 24 kyoshida 2009-09-02 18:28:50 UTC
@cornouws: to me, yes.
Comment 25 cno 2009-09-02 18:36:50 UTC
*** Issue 59229 has been marked as a duplicate of this issue. ***
Comment 26 kyoshida 2010-01-26 15:28:45 UTC
*** Issue 108661 has been marked as a duplicate of this issue. ***
Comment 27 hardy314 2010-11-13 16:50:03 UTC
This very confusing behavior is still happening in OOo 3.2.1. When I understand
this correctly, there exists a patch for it for 2 years now, so please fix this
soon. Thanks.

Voted for this issue.
Comment 28 niklas.nebel 2011-03-09 18:36:49 UTC
Fixed in CWS calc66, with a patch from the IBM Symphony team. AutoFilter now always includes additional rows. The Standard Filter dialog was already handled in ScDBFunc::GetDBData.
Comment 29 niklas.nebel 2011-03-15 14:43:47 UTC
Reassigning to QA for verification.
Comment 30 kla 2011-03-21 15:15:26 UTC
Seen ok in cws calc66 -> verified
Comment 31 Nelson Benitez 2012-01-30 13:36:46 UTC
Does anybody know if this got fixed in 3.3 ? or has to wait for 3.4?

thank you,
Comment 32 2012-01-30 16:11:05 UTC
> Does anybody know if this got fixed in 3.3 ?
> or has to wait for 3.4?

That feature (implemented by the Symphony team) is already in the development snapshots of Apache OpenOffice available at , so it will get into AOO34. The feature is not in OOo33 though.