Hi,
I am trying out filter expressions, which is really a great feature. A few things I noticed:
- when I enter # or !# in the filter editor then the value set back in the filter editor is #undefined and !#undefined. It seems that it is not checked if the value is present in the criterion (which it not is for # and !#), so the generated displayvalue is wrong.
- I saw this line of code in FormItem.parseValueExpressions:
if (key == "==" && valuePart.startsWith("=") && !valuePart.startsWith("==")) {
which can never be true, I get a:
Uncaught TypeError: Cannot read property 'ID' of null
when using == in a numeric field, it might be related.
- I set operator: 'equals' on a numeric field, still it tried to send iEquals to the server. For numeric fields can always the case sensitive value be send to the server? (I mean can casing be ignored)
This all in the build of 17th of July.
gr. Martin
I am trying out filter expressions, which is really a great feature. A few things I noticed:
- when I enter # or !# in the filter editor then the value set back in the filter editor is #undefined and !#undefined. It seems that it is not checked if the value is present in the criterion (which it not is for # and !#), so the generated displayvalue is wrong.
- I saw this line of code in FormItem.parseValueExpressions:
if (key == "==" && valuePart.startsWith("=") && !valuePart.startsWith("==")) {
which can never be true, I get a:
Uncaught TypeError: Cannot read property 'ID' of null
when using == in a numeric field, it might be related.
- I set operator: 'equals' on a numeric field, still it tried to send iEquals to the server. For numeric fields can always the case sensitive value be send to the server? (I mean can casing be ignored)
This all in the build of 17th of July.
gr. Martin
Comment