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

[Blama]

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):

isc.ListGrid.create({
    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
    fields:[
        {name:"countryName"},
        {name:"continent"},
        {
            name:"independence",
            getGroupValue : function (value, record, field, fieldName, grid) {
                if (value == null)               return "Ancient";
                else if (value.getFullYear() < 1910) return "Pre-Industrial";
                else                             return "Post-Industrial";
            }
        },
        {
            name:"population",
                        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"}
    ],
    groupStartOpen:"all",
    groupByField: 'population',
    autoFetchData: true
})

Please note how Brazil ("Down"-key) stays in the group and Canada ("Enter"-key) moves to the new group.


Best regards
Blama

[Blama]

Hi Isomorphic

actually, this might be related to this one.

Best regards
Blama

[Isomorphic]

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."

[Isomorphic]

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.

[Isomorphic]

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.

[Blama]

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
Blama

[Isomorphic]

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.

[Blama]

Hi Isomorphic,

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

Best regards
Blama