In the cellChanged event of the ListGrid object, the error specified by the setFieldError command disappears.

[eakduman]

In the Cell Change event of the Editable List Grid object, I am creating an error with the setFieldError command. But the error for the row that occurred, without changing anything in the same cell is entered and exit the error disappears.

Note : The same situation happens when any cell is clicked on the line with the error.

If you paste the code below into the example in this link, you will see the error.

https://www.smartclient.com/smartclient/showcase/?id=editByCell

isc.ListGrid.create({
    ID: "countryList",
    width:550, height:224, alternateRecordStyles:true,
    // use server-side dataSource so edits are retained across page transitions
    dataSource: countryDS,
    // display a subset of fields from the datasource
    fields:[
        {name:"countryCode", title:"Flag", width:40, type:"image", imageURLPrefix:"flags/16/", imageURLSuffix:".png", canEdit:false},
        {name:"countryName"},
        {name:"continent"},
        {name:"member_g8"},
        {name:"population"},
        {name:"independence"}
    ],
    autoFetchData: true,
    canEdit: true,
    editEvent: "click",
    editByCell: true,
    cellChanged : function (record, newValue, oldValue, rowNum, colNum, grid) {
          if ((newValue % 50) > 0)
                countryList.setFieldError(rowNum, "population", "Population has 50, 100, 150 etc...");
    },

});

[Isomorphic]

This is correct behavior - the "change" event fires when the value is in the midst of changing and can be rejected by your handler. If you set an error then, it is cleared because the value change is considered to have occurred only after your change handler has exited, which is the moment when the framework knows the value is going to be accepted.

While the "changed" (with a D) events fire at a better time, overall, you are much better off defining a validator for the field instead. With a validator, the framework can check whether the field still has an error at any time that may be necessary, including in complicated situations such as changes to related fields. With setFieldError(), you end up with a lot of situations where you may have to re-apply the error because the framework is making a reasonable assumption that it may not apply (due to new value, server save, etc).