I have tried pivot table functionality out again from the software “LibreOffice Calc 6.2.4.2-821.3” (Build-ID: 20(Build:2)). The filtering options “Case sensitive” and “Regular expressions” are described. https://help.libreoffice.org/6.2/en-US/text/scalc/01/12090104.html * It seems that they are applied to all selected columns so far. I would find it occasionally more appropriate to restrict these options to a smaller column list. * The information “If the Regular Expression check box is selected, you can use EQUAL (=) and NOT EQUAL (<>) also in comparisons.” was published. Will it be more helpful for this usage variant to offer less operators in the drop down list “Condition”? * How is the mentioned function list mapped to possible operators? https://help.libreoffice.org/6.2/en-US/text/scalc/01/12090103.html
(In reply to Markus Elfring from comment #0) > I would find it occasionally more appropriate to restrict these options to > a smaller column list. Please give an example. Thing is, providing options per entry (there are just two more) would bloat the dialog. The better approach is to introduce new column in the document for those complex scenarios and/or to filter the data that goes into the pivot table.
(In reply to Heiko Tietze from comment #1) > Thing is, providing options per entry (there are just two more) > would bloat the dialog. I find that software extensions will be needed for better selection of properties for filter criteria. Please take another look at application consequences around options like the following. * Case sensitive * Regular expression * Function list
I don't understand why you would need a filter like <Foo>="a" (case sensitive) AND <bar>="\n" (regular expression). And usually the table contains of numbers where these options are irrelevant.
(In reply to Heiko Tietze from comment #3) The property “Case sensitivity” matters for the application of regular expressions, doesn't it? > And usually the table contains of numbers where these options are irrelevant. I find this view too limited. Would you like to take any more contents (with other data types) better into account?
We had this topic on the agenda for the weekly design meeting. Having options for each of the 3 parameters is an overkill and impairing usability. So closing as WFM.
(In reply to Heiko Tietze from comment #5) > Having options for each of the 3 parameters is an overkill and impairing usability. I got other application expectations. I hope that this view can be reconsidered. > So closing as WFM. Would other contributors like to adjust the software situation any more?
Will any nicer solution ideas appear?