Hello Michael,

Thank you for contacting Infragistics!

I created a sample to test this behavior and when I tab from the last cell in a row it goes to the first cell of the next row and enters edit mode on that cell. I am attaching a sample demonstrating this behavior. I use 15.2.20152.2081. What version do you use? Do you have a sample that reproduces the behavior you are seeing?

Hi Mike,

the issue only occurs when using a custom Editor (which is extending EditorProviderBase) and if there is no next editable column in the same row and you have changed the value in the custom Editor.

I will try to create an example.

Michael

Hi Mike,

I already sent a reply but it get lost - do not know why.

So again:

I have adjusted your example:

1) I have added my custom Editor for the Name column.

2) I have set all other columns to read only

3) I have set autoCommit to false (important!)

4) In cellEditingEnded I have added a commit

With These modifications, the behavior is reproducible. I have attached a zip with the modified example. The file SQS.extendedmultilineeditor.ks contains the custom Editor.

To reproduce the behavior, follow this Scenario:

1) In row 2 (or subsequent rows) do a Change.

2) Press tab key to end editing

3) igGridUpdating is jumping to Name column in first row.

One add on: Commiting the entire table or just the edit row Shows the same behavior. So

                                                                $(ui.owner.element).igGrid("commit",ui.rowID,evt);     

and

                                                                $(ui.owner.element).igGrid("commit");     

Have the same Problem. If you are commenting the line, it is working fine.

Thanks for your help.

Hello Michael,

Thank you for the update. I have logged this for further investigation with my team with the ID 212386. I have also created a private case where I will provide you with further information.

Hi Mike,

thanks for info. Please let me know if there will be a chance for a fix. Otherwise we have to check to go with 2015.1, because autoCommit=true is not an option for us. We would like to go with 2015.2 because you have fixed 2 other issues we had with 2014.2 (enter long text in single line text column and wrong height calculation when using rowVirtualization but having only few rows). For these we have workarounds - but it would be great to get rid of them. So just let me know if a fix will be possible for 2015.2.

Michael

Hello Michael,

Thank you for the update. I have run your sample and I have been able to reproduce the behavior you describe. I am currently looking further into this matter to see what may be causing this issue. It appears you can you use autoCommit as a workaround for the meantime. I will update you with my progress.

Any news to this. This is really urgent for us, because it breaks some major functionality we have.