Announcement

Collapse
No announcement yet.
X
  • Filter
  • Time
Clear All
new posts

    Filterexpressions: smaller issues

    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

    #2
    We've resolved the first issue and it will be in tomorrow's nightly. Note that the line of source you reference can certainly be true and we didn't reproduce an error as you describe, but we did put a sanity check in to verify "valuePart" is a String before calling startsWith.

    On the second issue, as you say equals and iEquals are equivalent, we don't see a reason to complicate the logic by trying to use a specific operator here.

    Comment


      #3
      Hi,
      Yes you are right about the second point, my mistake.

      gr. Martin

      Comment

      Working...
      X