12.0p/12.1d ListGrid filterRow with allowFilterExpressions between-operator minor problem

[Blama]

Hi Isomorphic,

please open this sample (v12.0p_2019-07-22, also in 12.1d) and just remove one of the dots in "A...F", so that it is two dots, and hit enter.
This is wrong syntax and I'd expect it somehow to not work (empty filter field?), but you get a "undefined", which is definitely not expected.



Best regards
Blama

[Blama]

Hi Isomorphic,

I have another suggestion for this.

Colleagues of mine found this using our software. They did not know about the feature and just tried.
The syntax to enable filter operators on the left in the screenshot in #1 might be for heavy users that must be taught this in some help document.
But the normal end user can also select from the right click menu, which is pretty easy to understand for everyone.
There is only a problem with operations taking many values like inSet, notInSet, between, betweenInclusive.

Here it would be good if you showed the expected syntax somewhere, perhaps in the icon hover:



Best regards
Blama

[Isomorphic]

We've addressed the bug you noted. Operators with valueType "valueRange" (the various "between" variants) are unique, in that they require that the operator symbol ("...") be present any time the value is parsed as an expression, because we need a way to detect the two distinct values which are always required for those operators.

Now, in this situation, where the selected operator is *already* a valueRange operator, if you remove one of the dots, such that there is no longer a valid expression, the field will switch to it's default operator - in this case, iContains - and apply the entire value, as a string with 2 dots in it, to that operator. So it likely won't match any data. If you then reinstate the missing dot, it will re-detect the valueRange operator.

You can test that out in recent builds of recent branches.

We've also added Operator.usageHint, and various i18n class attributes to isc.Operators, in the format {valueType}UsageHint - like Operators.valueRangeUsageHint. These changes are available in 12.1 only.

[Blama]

Hi Isomorphic,

I had a look at it in 12.1d (SNAPSHOT_v12.1d_2019-07-31). The usageHints really help and are end user friendly, thanks a lot. Also, the "undefiend" problem is fixed for me like you say (switch to contains) in 12.0p and 12.1d.

The only thing (really minor) I saw is that in 12.1d the hints for between/betweenInclusive do have different linebreaks, resulting in a very wide hint for between.

Thank you & Best regards
Blama

[Isomorphic]

Part of the fix was to increase the default of Canvas.hoverAutoFitMaxWidth in 12.1, so that short hover-phrases like "contains (default)" don't wrap (at 100px), but larger text like usageHints *do* wrap (at 200px).

It looks like we have a separate bug in that sub-system - we'll take a look and get back to you.

[Isomorphic]

This one's been fixed for builds dated August 7 and later - ListGrid wasn't correctly propagating hoverAutoFitWidth/MaxWidth (noticable with header hovers also).

[Blama]

Hi Isomorphic,

I can see that it is working as expected using SNAPSHOT_v12.1d_2019-08-07.
By chance I saw a most likely timing and/or component re-use related case, where this does not work as intended. It has absolutely no priority for me, but perhaps it is important for you for some other reason.
See this 12.1d video of the sample when filtering for "Agana...F".



When you how the value hover for a very short time, then the operatorHint-hover has the old width issue.
It does not always happen for me as it is clearly timing related.

Best regards
Blama