Hi there,
I am having a strange bug with the IntializeRow event handler arguments.
I have a grid with custom sorting. In one of the cells of the grid, I put an image with an associated javascript in which one of the parameters is the e.Row.Index property of the RowEventArgs e. I use this to know on the browser javascript in which row the click was done.
This works fine except in one case: when the column I use for sorting has repeated elements. In this case, the InitializeRow fires for every row as expected, but the row number 0, for example, is not shown on the 0 position of the grid, but later. This breaks my program because when I click on the image of the cell, the javascript receives a row number of another row, and the results are completely unexpected.
I know it is hard to explain, let me know if I didn not made myself clear.
Any ideas on how to resolve this?
I made an example you can use too see what I mean.
You can download the web project here www.carrere.cat/GridTest.zip
To see how this is not working, open the web, click on the info images of every row to see that the rows are indexed correctly. After that, sort by status column and click on the info images to see that the row indexes are not corresponding to the actual row.
Pleas,e help us with this because this is completely breaking our sorting algorithm, since we sort correctly, but then the control renders every row where it wants.
I think that real issue is we don’t know the row’s Id in IntializeRow event using something like this e.Row.ClientID.
Still we can get the actual row in java script function as follow.
function Image_Click(sender)
{
var row = igtbl_getRowById(sender.parentNode.parentNode.id);
//row is the client side row object which contains image
//To avoid postback: return false
return false;
}
You need to change the image in following way.
<img src=”path” onclick=”BLOCKED SCRIPTreturn Image_Click(this)” />
Could you try this? Let me know if this works.
The problem here is that the e.Row.Index property on the InitializeRow event is one, and the actual row is rendered somewhere else in the grid (and not in the e.Row.Index position).
This disrupts the sorting, as I see the rows are being initialized sorted by looking at the e.Row.Index property every time the event gets fired (0,1,2,3, and so on), but then when the page is rendered, the rows are drawn in a different position (like row number 0 is in position number 13 or so). So our rows appear rendered as NOT ordered as we want.
If you download my web project that I posted and run it with a breakpoint on the InititalizeRow event handler you'll see that, after clicking on the column to sort, the row order is not mantained.
After sorting are you getting the repeated values side by side? Are they at proper position compared to other values in same column?
If yes then it means that the sorting is working fine. The things you need to do is providing second sort column name. It means that if Statuses are same then it should be sorted on Username.
Could you provide actual UltraWebGrid1_SortColumn? I think in sample it is not doing the actual work.
Is order of row initialization in UltraWebGrid1_InitializeRow important for your application? What exact operation you want to perform in UltraWebGrid1_InitializeRow? Or it is only for testing purpose?
The ordering is left blank on purpose. What I don't understand is why if the event is canceled and the messages are bounded exacty in the same way as in the Page_Load, then the rows are changed. And note that the indexes found by the Initialize method and the ones on the rendering are different. I use my InitializeRow event to paint some custom images on some cells, and to add some javascript logic to know the row id on the clientside.
I managed to solve it by saving the order on the InitializeRow event and then on the DataBound event (which is fired after) y reorder the rows by removing and adding it by index in the collection again, but this is a temporary solution that I'd like not to use because it's not elegant.
Please I'd like to know about this from the developers because I consider it's a bug and should be resolved.