Hi,
since using 2015.2 I am facing the following issue: When pressing tab in the last column or enter in any column, editing continues always in the first row of the table.
In 2014.2 is works fine: Enter moves to the same column in the next row, Tab moves to the next editable column in the next row.
I cannot see any new options. Is it a bug in 2015.2 or am I doing something wrong?
Merry Christmas and a Happy New Year!
Michael
Sorry. Forgot to mention some basic configurations:
1) I am using cell edit mode
2) I am using row virtualization
3) Only "Updating" is enabled as additional feature.
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,
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.
Any news to this. This is really urgent for us, because it breaks some major functionality we have.
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.
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.
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.