I have an interesting issue here.
I am intercepting the auto postback flag for RowSelectionChanged for a WebDataGrid with Virtual Scrolling enabled, EnableAjax false (require notification of autopostback flags), and EnableDataViewState false. The Grid loads data as necessary once it scrolls far enough.
If I select a row on a WDG the RowSelectionChanged argument returns a row object. No problem there. Where the problem occurs is when the grid needs to load more data, and the selected row has scrolled out of view, selecting another row returns a RowSelectionChanged event indicating the right number of selected rows, but each row object is null! Additionally, there are other strange issues, such as the scroll bar not working (although the mouse wheel does), and the control becoming unresponsive to mouse clicks (until what appears to be the grid 'catching up' which can take many seconds).
The reason why EnableAjax was turned off is that, by specification, I cannot utilize the existing editing features of the grid and must present a panel for editing consisting of standard controls. Thus, I need server side access to the row selection changed event. I could write the fill portion with client side code, however, I'd prefer to perform this on the server side.
I have gotten around the issue temporarily by setting EnableDataViewState to false, however, this effectively loads the entire set of data, regardless of the virtual scrolling setting, which I'd like to avoid.
I feel like I'm doing something extraordinarily unrecommended here, so my question(s) are...
Can you get virtual scrolling/on-demand loading to work properly when Ajax has been disabled? And by properly, I mean, selection events propagating to the server side with correct data, and free of strange side effects on the client? If so, how?
I'm seriously hoping that this is just a settings issue.
Hello Lill,
This method was introduced in one of the service releases.
Please install the last service release of 2009.2 and let me know if you need further assistance regarding this.
Lyuba,
I have the same problem where selected rows is null in a webdatagrid after ajax lookup.
I tried your work around, but GetIDPair is not recognized.
I am running netadvantage release 2009-2.
Hello Charles,
Thank you for your feedback. We appreciate that you took the time to convey your comments and I assure you that we consider our customer community comments very important to steering improvement at Infragistics. Your correspondence will be forwarded to the appropriate management for review and consideration.
I just want to explain the change that was introduced with the latest service release: the Row is not removed from the SelectedRows collection, and it is still null when yoo try to take it from the SelectedRows collection, but now it is possible to take its primary key:
if (WebDataGrid1.Behaviors.Selection.SelectedRows[0] == null)
{
object[] key = WebDataGrid1.Behaviors.Selection.SelectedRows.GetIDPair(0).Key;
}
Hope this helps.
Regards,
Lyuba
Developer Support Engineer
Infragistics
www.infragistics.com/support
Granted, what you suggest would be correct, that once new rows are requested the row would be "deselected", however, is that intuitive?
I don't know about you, but I would think that just when a row is selected and then scrolled out of the data view does not negate the user's (and developer's for that matter) perception that a row HAS been selected. While your assessment of the issue would prevent items not in the current row selection from being null and creating potential bugs/issues for the developer, it does NOT address the confusion of selecting a row and then having it deselected simply because the user operated the scroll bar or mouse wheel.
The answer to this is when rows are selected is to persist the data from selected rows when new rows are requested.
The fact of the matter is that, regardless of the intended modes of operation and tested scenarios of the control, it is expected that a grid control allow code-behind interaction that is reliable and necessary. It is unreasonable to expect that the user will be circumspect about losing critical interaction functionality simply because a particular mode is chosen, especially if the intended use for a particular mode is not well documented.
I don't mean to be particularly critical, however, I am more than just a bit puzzled with a grid control which does not easily surrender its contents and can do so reliably, as it is this data that is often crucial to implementing business rules and functionality. Indeed, I've spend more time working around the lack or odd implementation of what I would perceive to be basic and obvious functionality than I have actually implementing the business rules associated with that data.
I understand that development is often a piecemeal process, so I hope you will be kind enough to pass along these criticisms to your development team for their consideration.
The selection is lost because the selected rows are not persisted when the new rows are requested during the scrolling. What is not correct in the described scenario is that the row that was selected before the scrolling(and the requesting of new rows) is still included in the SelectedRowsCollection. I will create a support ticket on your behalf to investigate this issue further.