Dear Telerik Team!
If I use .navigatable() and Editortemplates (UIHint Attribute) it is not always possible to edit a cell. If I
- have about 1 to 2 thousand rows in a scrollable grid
- and select a cell using the mouse with template to start editing it
- and click fast, which means that there are just a few milliseconds beetween mousedown and mouseup
the the cell enters edit mode, but immediately jumps back to view mode a few milliseconds later without any user intervention.
If I click the mouse slower, meaning that there is a larger timespan beetween mousedown and mouseup the cell stays in edit mode.
I observed this behaviour reproducable in two different projects. I attached one of them.
(The attached project is not in a runnable state because of size restrictions in the forum. You have to add the telerik stuff yourself)
The bug can be experienced at least with actual Internet Explorer and Firefox. The latest Telerik version I am Using is 2014.1.415
If You are sure the bug is fixed in a newer version please inform me.
brgds
Malcolm Howlett
If I use .navigatable() and Editortemplates (UIHint Attribute) it is not always possible to edit a cell. If I
- have about 1 to 2 thousand rows in a scrollable grid
- and select a cell using the mouse with template to start editing it
- and click fast, which means that there are just a few milliseconds beetween mousedown and mouseup
the the cell enters edit mode, but immediately jumps back to view mode a few milliseconds later without any user intervention.
If I click the mouse slower, meaning that there is a larger timespan beetween mousedown and mouseup the cell stays in edit mode.
I observed this behaviour reproducable in two different projects. I attached one of them.
(The attached project is not in a runnable state because of size restrictions in the forum. You have to add the telerik stuff yourself)
The bug can be experienced at least with actual Internet Explorer and Firefox. The latest Telerik version I am Using is 2014.1.415
If You are sure the bug is fixed in a newer version please inform me.
brgds
Malcolm Howlett
4 Answers, 1 is accepted
0
Hi Malcolm,
Depending on the current PC setup of the user and the data loaded in the Grid it's possible to observe such behavior in some cases when the user tries to open given cell for editing faster than the browser is able to close the last edited cell (as each operation requires traversing and modifying of the DOM).
The "Navigatable" option of the Grid adds additional layer of complexity by adding more event handlers to the Grid rows/cells in which the current element is selected and previous selection is removed based on complex logic. That why turning it off improves the Grid performance which on other hand prevents the user from reproducing the previous behavior.
In current case I would suggest to try reducing the page size of the Grid or use "InLine" / "PopUp" edit modes.
Regards,
Vladimir Iliev
Telerik
Depending on the current PC setup of the user and the data loaded in the Grid it's possible to observe such behavior in some cases when the user tries to open given cell for editing faster than the browser is able to close the last edited cell (as each operation requires traversing and modifying of the DOM).
The "Navigatable" option of the Grid adds additional layer of complexity by adding more event handlers to the Grid rows/cells in which the current element is selected and previous selection is removed based on complex logic. That why turning it off improves the Grid performance which on other hand prevents the user from reproducing the previous behavior.
In current case I would suggest to try reducing the page size of the Grid or use "InLine" / "PopUp" edit modes.
Regards,
Vladimir Iliev
Telerik
Check out the Telerik Platform - the only platform that combines a rich set of UI tools with powerful cloud services to develop web, hybrid and native mobile apps.
0
Malcolm
Top achievements
Rank 1
Rank 1
answered on 17 Sep 2014, 02:07 PM
Err...
1. The behaviour can also be "observed" if there is no cell edited before. And it's really weird because the behaviour depends on the speed of the mouse click.
2. I am not really happy with the way You react to a obvious bug here. The behaviour is easy to reproduce and makes the component unusable. If there are features that break the grid control like scrolling, uitemplates and navigatable option, why do You provide them? Are there any plans to fix the bug?
1. The behaviour can also be "observed" if there is no cell edited before. And it's really weird because the behaviour depends on the speed of the mouse click.
2. I am not really happy with the way You react to a obvious bug here. The behaviour is easy to reproduce and makes the component unusable. If there are features that break the grid control like scrolling, uitemplates and navigatable option, why do You provide them? Are there any plans to fix the bug?
0
Hi Malcom,
Apologize if I was not clear enough - the described behavior is not a bug but is result of the amount DOM elements, event handlers, and other complex logic that is needed in order to render the Grid and add support for different browsers as well as the "InCell" edit mode and the navigation functionality. I can assure you that our dev team already made it's best to improve the Grid performance in previous releases and currently I could only suggest to use one of the following solutions:
Vladimir Iliev
Telerik
Apologize if I was not clear enough - the described behavior is not a bug but is result of the amount DOM elements, event handlers, and other complex logic that is needed in order to render the Grid and add support for different browsers as well as the "InCell" edit mode and the navigation functionality. I can assure you that our dev team already made it's best to improve the Grid performance in previous releases and currently I could only suggest to use one of the following solutions:
- Reducing the "PageSize" option of the Grid (reduces the amount of the elements and event handlers)
- Changing the edit mode of the Grid to "InLine" or "PopUp" edit mode
If you believe that you found a way to improve current behavior I would suggest to share your idea at Kendo UI UserVoice to allot other users vote and evaluate it. We are very open minded and carefully listen to our community's feedback - that why most voted ideas are included in next KendoUI releases.
Regards,Vladimir Iliev
Telerik
Check out the Telerik Platform - the only platform that combines a rich set of UI tools with powerful cloud services to develop web, hybrid and native mobile apps.
0
Malcolm
Top achievements
Rank 1
Rank 1
answered on 18 Sep 2014, 10:57 AM
I am not complaining about performance here. If it takes a few houndred milliseconds to enter edit mode in a large grid, it is OK. But if the user is not able to edit a cell allthough the control is used correctly, it is surely an error! I also stated that your description is at least partly wrong.
I clearly understand that it might not be easy to solve! Timing of events in js is sometimes weird.
Somehow the control must be triggered to leave edit mode without reason. This is not due to browser or DOM, but to Telerik. And I am sure it is possible to avoid this action if there is no indication to leave the edit mode. Maybe the control has to save if the user requested to edit a cell and avoid leaving edit mode if such a request is pending.
To use inline or popup edit mode is not an option in our case.
I think it is clearly not my responsibility to find a way to solve Your bug and let other users vote for it!
I would at least expect that such a basic error is recognized and fixed in a later version.
rgds
Malcolm Howlett
I clearly understand that it might not be easy to solve! Timing of events in js is sometimes weird.
Somehow the control must be triggered to leave edit mode without reason. This is not due to browser or DOM, but to Telerik. And I am sure it is possible to avoid this action if there is no indication to leave the edit mode. Maybe the control has to save if the user requested to edit a cell and avoid leaving edit mode if such a request is pending.
To use inline or popup edit mode is not an option in our case.
I think it is clearly not my responsibility to find a way to solve Your bug and let other users vote for it!
I would at least expect that such a basic error is recognized and fixed in a later version.
rgds
Malcolm Howlett