I am working on a project that requires a pinned, editable row for updating the values of an entire column. I would like to just co-opt the AddRow for this purpose, since its distinction from the data source and unique appearance make it pretty well suited to such a task.
I would like to disable the intended functionality of the AddRow, since that capability is not needed by the application I'm working on. I had some success removing the mappings for the Enter and Tab keys - you couldn't add the row without those two keys, as far as I was able to tell. But, this means I need to handle the appropriate actions for those cells in the rest of the grid with my own code.
I'm wondering if you can suggest an alternative, such as identifying an event I could handle and cancel to prevent new rows from being added to the grid via the AddRow UI element. Thanks.
Hello,
I am not sure why would you want to take this road, you could set the 'AllowAddNew' to 'No', like this:
ultraGrid1.DisplayLayout.Bands[0].Override.AllowAddNew = AllowAddNew.No;
Please let me know if you feel that I misunderstood you.
Sorry for not making this more clear. I want to display the AddRow, I'm using the setting FixedAddRowOnTop to display it. I want to ignore its intended use of adding rows. Instead I want to use it for entering data which, after a user presses a button, will affect all the rows in the grid below the selected column.
The two triggers I'm aware of that cause a new row to be added from the AddRow's content are when a user presses enter or tabs out of the last cell of that row. I need to prevent these two actions and any others from triggering the row addition.
If it helps you to understand why I want to do this, here's a basic rundown of how I use this grid:
The AddRow being distinct in several ways from a regular row will make a lot of these tasks easier and more reliable, without having to constantly check the row index or key value.
Hi,
I'm not sure, but I don't think this will work. There's no way to disconnect the AddNew row from it's intended functionality. In fact, in order for the AddNewRow to display and go into edit mode, it has to create a row in the data source and there's no way to stop that.
It might be easier to use a regular row instead of the AddNewRow.You can fix any row to the top of the grid, it doesn't have to be an AddNew row. The only down side to this approach would be that it requires the row to exist in the data source. But you would have that same issue with the AddNew row, anyway, only worse.
Another option would be to use a second grid with a single row and the same columns as the "real" grid. You'd have to write some code to keep the column widths and positions in synch, but this could be handled pretty easily in the AfterColPosChanged event.
Thanks Mike. I was considering having the second grid above the main one, but I thought the column arrangement would be tedious. I'll try using that event and see how it works out.
It will depend a lot on what features of the grid you are using. If you have a pretty simple single-band grid and you are not using RowLayouts, then synchronizing the VisiblePosition and Width of each column should not require too much code.
If you add in Fixed column, Groups, RowLayouts, and things of that nature, it will probably become unwieldy.
You might have some trouble with the VisiblePositions. I recommend that you always set them in order from 0 and up. Otherwise you will get unpredictable results. What I typically do is create a List<UltraGridColumn> and then sort the list based on the VisiblePosition of each column. Then I can loop through the list and set the VisiblePositions in the correct order.