https://issues.apache.org/ooo/show_bug.cgi?id=124957
mroe <[email protected]> changed: What |Removed |Added ---------------------------------------------------------------------------- Issue Type|DEFECT |ENHANCEMENT --- Comment #4 from mroe <[email protected]> --- (In reply to [email protected] from comment #3) > I'm no calc expert but the behaviour suggests that there is a bug when it is > determined whether a literal or a regexp comparison should be done between > the strings. In literal comparison "dword<=d.*" is false, because the > codepoint of 'w' is bigger than the codepoint of a dot. Only for the > equality-check the regexp seems to be active... Ahh. That's why the option explicitly says: "Search criteria = and <> must apply to whole cells" (to make it compatible to Excel). This explains my observations stated in comment 1 in an other way: For the expression X.* and a defined string Xstring the result will be (Xstring <X.*) = (Xstring < "X.*") = FALSE (non regexp) (Xstring =X.*) = ((MIN(X.*) <= Xstring <= MAX(X.*)) = TRUE (regexp) (Xstring >X.*) = (Xstring > "X.*") = TRUE (non regexp) Thank you! For reporters problem the easiest solution is without regexp: |Name |Name |>=b |<e condition area: A9:B10 with regexp: |Name |=^[b-d].* condition area: A9:A10 I think < and > with regexp isn't meaningful, because there IS a pattern match or IS NOT. What would be the "right" solution for [3-7] > 5? (Is 5 greater than 3 to 7 or not?) So I suggest to close this issue as NOT AN ISSUE. -- You are receiving this mail because: You are the assignee for the issue. You are watching all issue changes.
