Apache OpenOffice (AOO) Bugzilla – Issue 85305
Dynamically grow a filtered range for autofilter, standard filter, and advanced filter
Last modified: 2017-05-20 10:32:05 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.
Created attachment 50914 [details] file that stores out-of-date filtered range
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.
Created attachment 50915 [details] proposed patch
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 const-correctness.
setting target to 3.0.
@nn: can you take a look at this patch when you have a chance? Thanks.
Seems to be great feature.
Thanks for the patch, that would enhance greatly the user experience.
Created attachment 51917 [details] revised patch
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.
setting MS interop keyword.
Is there a milestone where we can test this new feature?
@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 [ http://go-oo.org/download/ ].
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.
@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.)
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.
Kohei, have you had a chance to update your patch after Niklas revewed it? Regards, K. Palagin.
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.
What do you think about having single database range for both filtering and everything else?
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... ;-)
Any news about the possible integration of Kohei's patch?
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.
Isn't issue 59229 about the same problem?
@cornouws: to me, yes.
*** Issue 59229 has been marked as a duplicate of this issue. ***
*** Issue 108661 has been marked as a duplicate of this issue. ***
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.
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.
Reassigning to QA for verification.
Seen ok in cws calc66 -> verified
Does anybody know if this got fixed in Openoffice.org 3.3 ? or has to wait for 3.4? thank you,
> Does anybody know if this got fixed in Openoffice.org 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 http://s.apache.org/Jqc , so it will get into AOO34. The feature is not in OOo33 though.