Announcement

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

    12.1p+ ListGrid Filter operator check mark missing (with allowFilterExpressions)

    Hi Isomorphic,

    please see this modified testcase (v12.1p_2023-06-14, v13.0p_2023-06-21) and notice in the video how the check mark for the filter operator in the filterRow context menu is missing after entering "~Ham".

    Best regards
    Blama

    Code:
    isc.ListGrid.create({
        ID: "countryList",
        width: 550,
        height: 300,
        alternateRecordStyles: true,
        dataSource: worldDS,
        fields: [
            { name: "countryCode", width: 60 },
            { name: "countryName" },
            { name: "capital", defaultOperator: "equals" }, // Changed
            { name: "continent" },
            { name: "area" },
            { name: "population" }
        ],
        autoFetchData: true,
        showFilterEditor: true,
        allowFilterOperators: true,
        allowFilterExpressions: true, // Added
    });

    Click image for larger version

Name:	Filter operator check mark missing.gif
Views:	86
Size:	181.6 KB
ID:	270368

    #2
    Thanks for the report - this appears already fixed in newer versions - we'll take a look and update here when we have more information.

    Comment


      #3
      In fact, this has not been addressed in newer builds - the entry in the menu is for "iContains" but, in this case, the expression-parsing code has apparently chosen "contains", which isn't in the menu.

      We'll update here once it's been fixed.

      Comment


        #4
        Hi Isomorphic,

        you might have a point here. By setting defaultOperator: "equals" I accidentally (I wanted to match behavior from my app) enabled this:
        By default, the case-insensitive version of the operator is used (eg, startsWith will actually use "iStartsWith"). To avoid this, explicitly set item.operator (the default operator) to any case sensitive operator (eg "equals" or "contains") and case sensitive operators will be used for user-entered expressions.
        So I made my "~" case sensitive, but the entry in the context menu is the case insensitive one. So it's perhaps correct, that the entry is not marked, because it's not the correct one.
        Perhaps the newly triggered case sensitive contains should be dynamically added to the context menu, or just leave everything as it is.

        Best regards
        Blama

        Comment


          #5
          We agree and we've made a change to allow the detected (case-sensitive) operator to appear separately in the Operator-menu. It will only appear there as long as you have it selected as a result of having entered it as an expression.

          You should be able to try this out in today's builds, dated June 27, or a later one.

          Comment


            #6
            Hi Isomorphic,

            I can see this is changed and working in v12.1p_2023-06-27.

            Thank you & Best regards
            Blama

            Comment

            Working...
            X