This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
1. Connect to "sample" Java DB. 2. Rightclick PRODUCTS table and choose "View Data". 3. Type 'sw' in matchbox. Result: Nothing is shown. 4. Type 'SW' in matchbox. Result: Matched data is shown. Matching process should be case insensitive. But actually even better let customer choose this option (if possible).
Reassigned to new owner.
Ok - the problem lies in the way the "MatchBox" and the "SuperPatternFilter" work. Basicly the changeset 164717, 165654 break the filter. In DataViewUI.java (line 522): filterP.setFilterStr(matchBoxField.getText(), REGEX_FIND); So I(!) would expect, that the supplied string is matches by interpreting it as a regular expression and using the find method on the column content. WRONG! After the above mentioned changesets REGEX_FIND basicly does a case sensitive search, because the regexp is quoted in SuperPatternFilter.java (line 92) and so not uses as a regexp, but applied literaly. So I propose to revert the changes from both changeset on SuperPatternFilter.java (these introduced what I would call bugs). And instead change DataViewUI.java (line 522) to: filterP.setFilterStr(matchBoxField.getText(), LITERAL_FIND); That fixes this bug, makes the whole thing take less CPU time and follows the description of the Match Option.
(In reply to comment #2) > Ok - the problem lies in the way the "MatchBox" and the "SuperPatternFilter" > work. Basicly the changeset 164717, 165654 break the filter. What changesets? I cannot find it on http://hg.netbeans.org/. Could you link them? Thanks > In DataViewUI.java (line 522): > filterP.setFilterStr(matchBoxField.getText(), REGEX_FIND); > > So I(!) would expect, that the supplied string is matches by interpreting it as > a regular expression and using the find method on the column content. WRONG! > After the above mentioned changesets REGEX_FIND basicly does a case sensitive > search, because the regexp is quoted in SuperPatternFilter.java (line 92) and > so not uses as a regexp, but applied literaly. > > So I propose to revert the changes from both changeset on > SuperPatternFilter.java (these introduced what I would call bugs). And instead > change DataViewUI.java (line 522) to: > > filterP.setFilterStr(matchBoxField.getText(), LITERAL_FIND); > > That fixes this bug, makes the whole thing take less CPU time and follows the > description of the Match Option.
(In reply to comment #3) > (In reply to comment #2) > > Ok - the problem lies in the way the "MatchBox" and the "SuperPatternFilter" > > work. Basicly the changeset 164717, 165654 break the filter. > What changesets? I cannot find it on http://hg.netbeans.org/. Could you link > them? This is the first time the meaning of "REGEX_FIND" and "REGEX_MATCH": http://hg.netbeans.org/main-golden/rev/a45fa947a776 and the second time: http://hg.netbeans.org/main-golden/rev/8e5ea5fb080e The SuperPatternFilter.java was ok before these changes, it was just called with the wrong options. The problems in the mentioned bugs in the changes arise from the expectation of the user, that the box does a plain search, but was in realtity expecting the user to enter an regexp. This: filterP.setFilterStr(matchBoxField.getText(), LITERAL_FIND); will do an case insensitve search on the string representation of the column value. That would be the use case of this bug. If the search should be case sensitve it would be better to change this: return valueStr.toUpperCase().contains(filterStr.toUpperCase()); to this: return valueStr.contains(filterStr);
matthias, I believe your evaluation, proposed changes applied in http://hg.netbeans.org/core-main/rev/294c1c857218 Thank you
Integrated into 'main-golden' Changeset: http://hg.netbeans.org/main-golden/rev/294c1c857218 User: Jiri Rechtacek <jrechtacek@netbeans.org> Log: #155820: There should be possibility to case insensitive match