After correcting a column of 250,000 numbers it tries to write 250,000 cell addresses into a list box which takes by a magnitude more time than the replacement process. In fact I killed the process and fired up OpenOffice. If such feature is really, really desired by the Excel fans, then it should be possible to disable it. Furthermore, such feature should be supervised by an experienced Calc developer who knows that a search run returns a collection com.sun.star.sheet.SheetCellRanges with interface XSheetCellRanges having method getRangeAddressesAsString. In my case, this method would return an array of one string "Sheet1.A1:A250000" http://www.openoffice.org/api/docs/common/ref/com/sun/star/sheet/XSheetCellRanges.html#getRangeAddressesAsString Issue #72413 has not been fixed in a satisfactory manner. The feature needs to be reimplemented by a more experienced Calc developer. And it needs a config option to get rid of it.
Can be considered as solved on tdf#92160?
@Andreas please take a look at bug 92160 as suggested by m.a.riosv and tell if your issue still persists. you need to test with a 5.2.4 or 5.3.0 pre-release http://dev-builds.libreoffice.org/pre-releases/ if bug is still there set back status to UNCONFIRMED if it's gone change it to RESOLVED FIXED NEEDINFO until then
Created attachment 129855 [details] Spreadsheet, Dialog, Basic
Dialog remains, has no means to disable. But results for large search/replace actions have been adjusted so that with 5.2.4 and 5.3.0 it does not show more than 1000 results. Done as part of resolving bug 92160, unfortunately the change from row based to column based replacement was not back-ported to 5.2, should move to a 5.3 branch for better performance with larger sheets. =-ref-= In 5.3 http://cgit.freedesktop.org/libreoffice/core/commit/?id=5946cc2f7056fc580fefe1b90795e3921bdb3969 https://cgit.freedesktop.org/libreoffice/core/commit/?id=ba68e6dd7ad99ef2a2720f327813d13550b98966 In 5.2.4 https://cgit.freedesktop.org/libreoffice/core/commit/?h=libreoffice-5-2&id=1a093a2c06c30c17e483614e36a75907e7d0991f
Makes sense to back-port to -5-2 - though IIRC there is a string-freeze concern there; anyone that wants to chase that is welcome - Andreas - can you confirm 5.3 works nicely for you again ? Thanks !
(In reply to Michael Meeks from comment #5) > Makes sense to back-port to -5-2 - though IIRC there is a string-freeze > concern there; anyone that wants to chase that is welcome - Andreas - can > you confirm 5.3 works nicely for you again ? > > Thanks ! Please check out my attached spreadsheet. It *should* be possible to display a search result as "A1:A1000000" instead of 1 million cell addresses A1, A2, A3, A4, ...
(In reply to Andreas Säger from comment #6) > Please check out my attached spreadsheet. It *should* be possible to display > a search result as "A1:A1000000" instead of 1 million cell addresses A1, A2, > A3, A4, ... OK, and? At 5.2.4, 5.3.0 or with current master the "Search results" dialog showing just 1000 cells matching find all/replace all results is easily dismissed. And now imposes minimal performance impact (with bug 92160 resolved). The dialog provides a reasonable GUI of benefit to those that prefer/need to quickly navigate between find and/or replace occurrences on their sheets. Yes 1000 was an arbitrary count to show (as opposed to generating a complete table listing of the result)--but a selectable navigation GUI with those 1000 entries is of use to the majority of Calc users with now reduced overhead. And for those that do not find the interactive GUI useful, it can be immediately dismissed, leaving the cell selection for results available. Personally see no substantial benefit to doing anything additional with the dialog--but let's set an enhancement to give those folks that prefer so the ability to disable the GUI "Search results" dialog.
(In reply to V Stuart Foote from comment #7) > (In reply to Andreas Säger from comment #6) > > Please check out my attached spreadsheet. It *should* be possible to display > > a search result as "A1:A1000000" instead of 1 million cell addresses A1, A2, > > A3, A4, ... > > OK, and? > The feature is badly implemented. The cell by cell result is not informative and it is slow. With a proper implementation it could be useful without arbitrary limitations.
> The feature is badly implemented. ... With a proper implementation You're absolutely right =) there is a set of ~7bn people who have not worked to improve this feature, it is hard to know who is responsible for not improving things in LibreOffice ! =) probably we can exclude the 5bn without a decent PC or internet access ... Anyhow ;-) in all seriousness; thanks for your report: this feature is a big improvement for many simple cases; for bulk replacement - you're quite right it would be great to have range based reporting - and now we go down columns, this should be really quite easy to aggregate. I would suggest you open up another bug with a feature enhancement there; if you'd like some code pointers to do the implementation - I'm happy to help with those - the referenced patch links should give the code pointers necessary. Then again - it is easy to imagine sheets that have a very large number of replacements which are not actually contiguous that would blow up our code in this regard again; so - I still believe we need to crop this one. Again - if you want to implement a config. option here - I happy to provide code pointers for that officecfg/ contains our configuration XML schema and defaults; and is compiled to helpful accessors $ git grep officecfg:: for some sample code there. All the best !
(In reply to Michael Meeks from comment #9) > Again - if you want to implement a config. option here - I happy to provide > code pointers for that officecfg/ contains our configuration XML schema and > defaults; and is compiled to helpful accessors $ git grep officecfg:: for > some sample code there. > Yes, please.
Great - so I would add the option to something like: officecfg/registry/schema/org/openoffice/Office/Calc.xcs That should then be compiled into a header something like: workdir/CustomTarget/officecfg/registry/officecfg/Office/Calc.hxx You can include that file with a #include <officecfg/Office/...> and then do something like: if (officecfg::Office::Calc::Filter::Import::VBA::UseExport::get()) But that's for a VBA option of course ;-) around the code that populates and shows this dialog which is in: sc/source/ui/dialogs/searchresults.cxx or somewhere around $ git grep SearchResultsDlg I guess =) Thanks !
*** Bug 83614 has been marked as a duplicate of this bug. ***
The issue is solved. The nasty thing can be switched off in the Calc options.
Fixed at 6.3.0 as for bug 87965 [1][2] providing control on the dialog, and in the Calc View options. But Heiko's patch also provides an Expert configuration boolean "SearchSummary" for the Calc Layout Window. Where 'true' will show the summary dialog (with max as for bug 92160 of 1000 results), and 'false' will suppress the summary. In the GUI the 'Summary on Search' checkbox on the Tools -> Options -> Calc -> View panel toggles the SearchSummary value true/false. And the 'Show this dialog' checkbox on the 'Search Results' dialog will set it false. =-ref-= [1] https://gerrit.libreoffice.org/#/c/71910/ [2] https://gerrit.libreoffice.org/plugins/gitiles/core/+/019c6ae2ee20a5923055c261abdd22575b69299b%5E%21
*** Bug 129472 has been marked as a duplicate of this bug. ***