I am adding rows via JavaScript into an UltraWebGrid with no paging (other than the slider). While adding new rows within the visible portion of the grid, all appears fine. Once a new row is added at the bottom of the grid, the new row's cell editing occurs below the grid's frame. Subsequent row additions cause each new row's cell editing to creep down the page. Also, the grid's vertical slider is not positioned at the very bottom even though this is the last row. It is as if the new row's cell editor has a miscalculated vertical offset because of an incorrectly inferred grid height.
I am using CLR3.5 version 10.1 and the grid is nested within a table (for positioning), an UpdatePanel, a ContentPane and (finally) a Master Page.
Any thoughts on how this is happening and how to avoid it? I have used various combinations of Cell/Row scrollToView() calls to no avail.
Hi dbengine.
That would be a lot of code. I can break down my process and, if you wish, I can upload the areas you may want examples.
Here is what I do:
1) Create VB/C# classes that simulate the JSON object I want my browser client to be able to work with. I can build a fully ragged hierarchy if needed. If I am dealing with NULL data, I often use Nullable(of T) for properties. If I am dealing with master/detail relationships, I often use generic.list(of T) for the relevent properties. The class hierarchy can be used to send data to the client as well as to receive the updated results from the client.
2) When the client needs data, it calls a web method (a page method would be okay, too). Using my data layer, I populate an instance of the class hierarchy I defined above. The return of the web method is my fully populated object hierarchy.
3) When the client completes the web method call, it has at its disposal, a fully populated object matching the definition of my classes (in step #1). I can populate my page controls directly on the client using this data. The internals of the web method call automatically translate my server object instance into a JS object using the magic of JSON serialization.
4) Since your question pertained to client-side grid row manipulation, I will provide a bit of sample code. You can put this code in the web method's success handler where it will have access to the data.
// Get grid reference
var Grid = igtbl_getGridById('<%= GridName.ClientID %>');
// Clear the grid of existing data.
while (Grid.Rows.length > 0) {
Grid.Rows.getRow(0).remove();
}
// Populate the grid by iterating through the received object's details (generic.list(of T) -> JS array)
for (var iDetail = 0; iDetail < ReceivedObject.Details.length; iDetail++) {
// Add a new row to the grid
var Row = Grid.Rows.addNew();
Row.getCellFromKey('LastName').setValue(ReceivedObject.Details[iRow].LastName, false);
5) When adding rows on the client side, the server will not see the changes to the grid. Instead, just repopulate the received object hierarchy with the data it needs and pass it to the "Save" web method (reversing the process outlined in steps 1 to 4.
I hope this helps.
Thanks dgcrg for sharing the instructions of how you resolved your problem of Adding New Rows to the bottom of the UltraWebGrid.
I am new to UltraWebGrid and also need to be able to add new rows programmatically or like what you did, on client-side is even better.
Is it possible that you can show me how to do it with code samples, please? Greatly appreciated.
It appears that the problem was the client's internal data-structures were becoming out of sync whenever an update (e.g. new row addition) to the grid was performed by the server.
For example, the UpdatePanel issues a server request and this server request needs to add a row to the UltraWebGrid. Upon return from the server request, if the newly added row was at the bottom of the grid, its edit cell would be positioned below the borders of the grid. Each subsequent row addition would result in the newly added row's edit cells being positioned lower and lower as if the grid was "bottomless".
I moved my update logic to an out-of-band AJAX call. This requires that, upon return from the call, all grid updates (cell values, row adds, etc) are performed via client JavaScript code. Result: the grid no longer gets out of sync with itself. Furthermore, each server request's payload is lighter -- only the required data is passed back and forth. Lastly, I have full control of when and how a server request is performed. This is important when the input cell has to reflect any newly added rows.
A little further detai:
The grid is performing an AfterCellUpdate postback to the server in order to retrieve values for the current row's cells based upon a cell's value entered. If the postback is not performed, the grid behaves perfectly. That is, rows are added and the cell's editor is properly positioned within the frame of the grid. If the postback is allowed to occur (even if the postback performs no operations), rows are added to the grid; however cell editing of the first column creeps down the page as described in the original post -- each subsequent row addition beyond those that fill the visible portion of the grid cause the grid's cell editor to move down the page.
The callback is necessary in order to retrieve cell values upon data entry.
Any suggestions, hacks, work-arounds?