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

  • 10.1p/11.1p: Inconsistent behavior on grouped ListGrid editorExit (Enter vs other, e.g down, click outside) when there is a validation error

    Hi Isomorphic,

    retesting this issue, I noticed a different behavior depending on the way I stop editing a row.
    "Enter" moves the row to the new group, even if there are errors, while a click outside the edit row and the "Down" key don't do this.
    I'd expect to behave "Enter" like the others. While the thread above is about a similar thing involving server errors, this here also happens for client side validation errors.

    Please see the modified customGrouping-sample (main change: client side validator added) in current 10.1p (v10.1p_2017-12-21) / 11.1p (v11.1p_2017-12-29):

        ID: "countryList",
        width:500, height:600, canEdit:true, sortField:"countryName", modalEditing:true,
        alternateRecordStyles:true, cellHeight:22,
        dataSource: countryDS,
        // display a subset of fields from the datasource
                getGroupValue : function (value, record, field, fieldName, grid) {
                    if (value == null)               return "Ancient";
                    else if (value.getFullYear() < 1910) return "Pre-Industrial";
                    else                             return "Post-Industrial";
                            validators: [{
                                        type: "integerRange",
                                        min: 1,
                                        max: 20000,
                                        errorMessage: "Please provide a reason"
                GROUP_SMALL: 1,
                GROUP_MED: 2,
                GROUP_LARGE: 3,
                getGroupValue : function (value, record, field, fieldName, grid) {
                    if      (value < 100000000)  return this.GROUP_SMALL;
                    else if (value < 1000000000) return this.GROUP_MED;
                    else                         return this.GROUP_LARGE;
                getGroupTitle : function (groupValue, groupNode, field, fieldName, grid) {
                    switch (groupValue) {
                    case this.GROUP_SMALL: 
                        baseTitle = "Population less than 100 million"; break;
                    case this.GROUP_MED: 
                        baseTitle = "Population between 100 million-1 billion"; break;
                    case this.GROUP_LARGE: 
                        baseTitle = "Population over 1 billion"; break;
                    baseTitle += " (" + groupNode.groupMembers.length + " members)";
                    return baseTitle;
           {name:"countryCode", title:"Flag", width:40, type:"image", imageURLPrefix:"flags/16/", imageURLSuffix:".png"}
        groupByField: 'population',
        autoFetchData: true
    Click image for larger version

Name:	Validation error group change.gif
Views:	1
Size:	110.8 KB
ID:	250970
    Please note how Brazil ("Down"-key) stays in the group and Canada ("Enter"-key) moves to the new group.

    Best regards

  • #2
    Hi Isomorphic

    actually, this might be related to this one.

    Best regards


    • #3
      We're looking into this, but we believe the correct behavior is what enter is doing - grouping by the edit value, even if a validation error is present. Not sure if that corresponds with the statement, "I'd expect to behave "Enter" like the others."


      • #4
        Note that for us, hitting enter and clicking outside both update the group - it's only the keyboard navigation to an adjacent row that has different behavior.


        • #5
          We've applied a fix to SGWT 5.1p/SC 10.1p and newer releases to make things consistent and all behave like the "enter" case you mention. This will be in the nightly builds dated 2018-01-11 and beyond.


          • #6
            Hi Isomorphic,

            using v11.1p_2018-01-11 this is now consistent for me, as you write. v10.1p_2018-01-11 still shows the old behavior for me. This doesn't matter to me, though and is only a FYI.

            Best regards


            • #7
              We're not able to reproduce the issue in SC 10.1p any more as of the 2018-01-11, so barring some repro method, it doesn't look like there's anything to be done.


              • #8
                Hi Isomorphic,

                sorry, you are correct. I can't reproduce anymore, so I don't know what I saw/did earlier today.

                Best regards