5.1p/6.0p: filterRow with inline operator filter doesn't recover from invalid entry

[Blama]

Hi Isomorphic,

please see this sample (v11.0p_2017-03-29) and enter <=22# in the filterRow for Area. and hit enter (on a German keyboard, "#" is next to "Enter", so this is a very possible mistake when typing fast).
It filters to 0 rows (expected). Now, if you notice the error and remove the # and hit enter again, there are still no rows found.

To fix, you have to remove the 22 as well, hit enter (as rows shown, as expected) and then enter 22 again.
A similar thing also happens in 5.1p in my application, where I found the issue.

Best regards
Blama

[Blama]

Hi Isomorphic,

in the same area, in both 11.0p and 11.1d, the display of the filter values in the filterRow does not seem to work.
Just see this sample (v11.0p_2017-03-29) and that the initialCriteria for the capital-column are not displayed in the filterRow, while the ones for the country-column are displayed.
The initialCriteria for the population-column are most likely not possible to display out-of-the box, as they are AdvancedCriteria.

But the same is true if you enter a...b for betweenInclusive in the country-column.
Please note that 1...1000 in one of the number-columns (area, population) does not work and is translated to "1".

Best regards
Blama

[Isomorphic]

It seems there's a problem in the automatic parsing that happens when filterOperators and filterExpressions are in use together, for criteria with complex operators - that is, ones where the expr does not just prefix the value, but also has a suffix expr, or like "...", the expr appears between values.

We'll take a look.

[Isomorphic]

On your first report - it's not valid, in that case, to type an expression that you expect to be interpreted (like "<=22") because allowFilterExpressions is not switched on in that sample.

You could switch it on to see what we mean, but you should wait until tomorrow, since numerous changes have been made today to fix items available in the operator menu for various fields, and to support those broken complex operators (like between and more complex advanced crit, like an "or").

The issue of between not working in numeric items is still outstanding and we'll update when it's fixed.

[Blama]

Hi Isomorphic,

thank a lot.
As 1st feedback, it has become better a lot (the sample from #2 is loading and displaying the filters as expected), but there are still problems in sample #1 (SNAPSHOT_v11.1d_2017-04-02, switched to SmartClient, as the SmartGWT showcase was not updated).
Also filtering for invalid values like "22#" seems to work way better now.
Small note: Filtering for "between" has a wrong logo (gray background instead of blue). But I assume you already know that if you are still working in that area.

Best regards
Blama

[Isomorphic]

When you say there are still problems in your first sample, what do you mean? That first sample doesn't support expressions, because allowFilterExpressions isn't switched on in that sample, so something like ">=22" would not be expected to be parsed into an operator and value - it would just be a different (possibly invalid) value.

[Blama]

Hi Isomorphic,

sorry, I thought there were problems and prepared steps to reproduce until I noticed that the error was on my side and there was filtering happening as expected. I then edited the post, but missed that part.
I did not see any issues so far.

Sorry for the confusion
Blama