Issue with addRowEditorExitHandler

[swatiagarwal]

SmartClient Version: v11.0p_2017-02-11/PowerEdition Deployment (built 2017-02-11)

I have a listgrid where i am editing and entering new records. In case user enters the same value for some field say field1, i display a error message and cancel the event. Code as below:

grid.addRowEditorExitHandler(new RowEditorExitHandler() {

@Override
public void onRowEditorExit(RowEditorExitEvent event) {
Map valuesMap = event.getNewValues();
fieldName = (String) valuesMap.get("fieldName");

if(fieldName1.equals("dummy")){
SC.say("Invalid value");
event.cancel();

}
}
});

But, now when the user changes anything in the same field and clicks outside the grid, the RowEditorExitHandler is not fired. It is fired only if i click on some other column and then click outside.
Please help.

[swatiagarwal]

Any help on this.

[stonebranch2]

Hi Isomorphic,

We are experiencing the same issue.

Do you have any follow-up on this one?

Thanks

SmartClient Version: v12.0p_2018-09-21/Pro Deployment (built 2018-09-21)

[Isomorphic]

We see one issue when applying the original sample code from the first post. If the event is canceled, showing the error dialog, from the user clicking outside the grid, further clicks outside the grid have no effect. You have to click back inside the edit row to ensure that clicking outside the grid will trigger the handler again. However, other means of triggering the editor exit handler don't have that problem, such as hitting return, or attempting to arrow navigate to the next row.

We'll look into what's causing the unexpected behavior when clicking outside and attempt to fix it.

However, there may be a larger issue here, judging by the original sample code. If you want to validate field content, you should just use our validators. Attempting to cancel the editor exit for "invalid" values as in the sample code will cancel it for all ways of exiting, including hitting escape, which likely is not an interaction the user will expect, since escaping is just going to discard all of the edits anyway.

[stonebranch2]

Thanks for the update.
Our use case wasn't quite the same as the above example, however, we found an alternative and cleaner option to meet our needs either way.