BuyLog In
Ticket T284236
Visible to All Users

GridView - Batch Edit - The SetValue method does not work if the Tab key is used for navigation to the next cell

created 10 years ago

Hi,

We currently have a MVC GridView with several columns.   Two of these columns are textboxes and are linked so that when one is changed, the other one is also changed based on a calculation.  The first column is also the first editable column from the grid.  The second column is the last editable column (we have another column after that which is not editable).

If we edit the first cell and hit the "tab" key, the "ClientSideEvents.ValueChanged" event is fired.  We then get the grid control related to this editor, get the editor from the other cell using "gridView.GetEditor()" and update its value with the "SetValue()" method.

If we do the same thing with the other cell, the "SetValue()"  only works if we click on another cell from the same row or another row ; if we use the "tab" key to change cell (and, since it is the last column for the row, changes the line), the "SetValue()" does not change the value from the first cell.

We do not get any javascript error and the first cell of the next row is not updated : it simply does not update when using the "tab" key, but it works if we click on another cell/row in the grid

Do you have any suggestion regarding this ?

Regards,

Comments (2)
Mike (DevExpress) 10 years ago

    Hello,

    This information is insufficient to provide you with an appropriate solution.
    Would you please elaborate on your scenario and describe the issue you have encountered in greater detail?
    - Provide us with a sample project (at least the full GridView definition and related JavaScript code) that demonstrates the issue in action.
    - Illustrate the actual and expected results with some screenshots.

    SN SN
    Sebastien Nadeau 10 years ago

      Hi,
       I have included a test project which reproduces the issue : the error happens when modyfing the "GrossAmount" field and hitting the "tab" to go to the next cell (here, the first editable cell of the next line).  If we click on another cell or row instead of using the "tab" key, the "ratio" value is correctly changed.   If we change the "Ratio" field, the "GrossAmount" is correctly modified

      Sign in to comment on this post

      Answers approved by DevExpress Support

      created 10 years ago (modified 10 years ago)

      Hello,
      Thanks for the clarification. The issue occurs since your changes are overridden by default logic performed when the BatchEditEndEditing event is raised.  Use the technique from the GridView - Batch Edit - How to calculate values on the fly example to accomplish this task.

      Thanks,
      Artem

        Show previous comments (10)
        DevExpress Support Team 7 years ago

          Hello Sebastien,

          Thank you for the clarification. The ValueChanged event is raised after the focus moved out of an editor. The focusing out is not considered complete until the next element is focused. When you press the Tab key in the last editor in a row, it moves focus to the first cell in the next row in Batch Edit mode. The grid should complete edit process in the current row to focus a cell in the next row. That's why the BatchEditEndEditing event should be raised before the ValueChanged event.

          As a result, the editor is not visible by the moment of the SetValue method executing: the current row is already switched to the browse mode. Moreover, since the value is assigned to the editor  when the row is not active and not processed by grid's Batch Edit code, the editor value is not applied to the modified Batch Edit cell value.

          This behavior is implemented intentionally and it is a part of the keyboard navigation functionality in GridView. It is possible to implement your scenario by using the approach suggested above. Would you please clarify why this solution does not meet your requirements?

          SN SN
          Sebastien Nadeau 7 years ago

            Hi,

            While we understand the current behavior and how you have implemented it, we would expect that all navigation methods (either by clicking on another row or switch to the next row with the "Tab" key) will result in the exact same behavior.  For us and our users, there is no difference between switching rows by click or by keyboard.  Some of them are using the click and some others, coming from an Windows-based environment, will prefer the Tab key (or even the "Enter" key) to navigate through the cells.  In both ways, the cell-related events and operations should be handled before quitting the row and going into the next one.

            If we do a "console.log" of the "ValueChanged" event and the "BatchEdit" event, the order is not the same if we use the mouse (ValueChanged, then EndEdit) than if we use the "tab" key (EndEdit, then ValueChanged).

            The user will not understand the event priority and will expect the same results while navigating.  If we put the column in another place than the last one, it will correctly update the other column.  The same is true if we hit "Shift+Tab" to go backward.  We do not understand why the last column should be handled manually by a custom javascript code while all the other situations are correctly handled natively.

            While we could implement your workaround again, we expected that this would be resolved since our initial discussion and would be a supported feature.  The problem is not that it will not work (it will since we already put it into another grid), but that we will have to manually handle each of our grids' row change that shows this behavior and that we will have to maintain this code if for example we move the column.

            We do not allow users to move, hide or show columns in a grid, but if that was the case we would have to handle every scenario in which an editable column with a defined "ValueChanged" event would be placed in the last positiion.   Our suggestion is also for the other Devexpress customers that may end up with this situation.

            We would greatly appreciate that this would be part of a fix ; we strongly believe that this is a bug in the navigation process.  While we understand that this is not a common scenario, we think that it would make a more consistent experience and it would help all Devexpress customers and their users.

            Regards,

            DevExpress Support Team 7 years ago

              Hello Sebastien,

              Thank you for bringing this to our attention, we completely understand your point. I need to say that the current behavior is a base for many scenarios and changing it may cause major problems in existing projects. On the other hand, the desired behavior can be implemented using our public API. In addition to that, we didn't receive other inquiries for changing the current events sequence. We will take your requirements into consideration, but currently we don't have plans to change this behavior.

              Sign in to comment on this post

              Disclaimer: The information provided on DevExpress.com and affiliated web properties (including the DevExpress Support Center) is provided "as is" without warranty of any kind. Developer Express Inc disclaims all warranties, either express or implied, including the warranties of merchantability and fitness for a particular purpose. Please refer to the DevExpress.com Website Terms of Use for more information in this regard.

              Confidential Information: Developer Express Inc does not wish to receive, will not act to procure, nor will it solicit, confidential or proprietary materials and information from you through the DevExpress Support Center or its web properties. Any and all materials or information divulged during chats, email communications, online discussions, Support Center tickets, or made available to Developer Express Inc in any manner will be deemed NOT to be confidential by Developer Express Inc. Please refer to the DevExpress.com Website Terms of Use for more information in this regard.