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

    Hi Isomorphic

    actually, this might be related to this one.

    Best regards


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


        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.


          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.


            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


              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.


                Hi Isomorphic,

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

                Best regards