Your Privacy Matters: We use our own and third-party cookies to improve your experience on our website. By continuing to use the website we understand that you accept their use. Cookie Policy
211
Ultrawebgrid in session variable
posted

Since we upgraded from Infragistics 2008.2 to Infragistics 2009.2 a problem has arised. Basically I want to save an UltraWebGrid in a session variable to keep its state as I move down in the page hierarchy and back. I save the grid, then read from the session variable to check that it has been saved correctly. And it has. I have an UltraWebGrid with the correct amount of rows and everything seems to be ok. I then do a Response.Redirect to another page, and in page load of the new page I read the same session variable again. And by then the UltraWebGrid has lost all its rows (and bands). Note that the session variable is not null, reading from it and casting it to an UltraWebGrid goes fine. But all rows are gone.

 

In the 2008.2 days I think we stored a RowsCollection in the session variable instead of an entire UltraWebGrid, but with 2009.2 the same thing happens there. Information is lost when moving between pages.

 

Any ideas?

Parents
  • 45049
    Verified Answer
    posted

    elwolfo said:
    I want to save an UltraWebGrid in a session variable to keep its state

    Typically, this is a dangerous approach to take with any ASP.NET control.  Remember that, with each postback, the instance of the control you have on your page will be a different instance than the one you stored in session.  More importantly, doing this will root your pages in the .NET object hierarchy, preventing the page and any controls on it from being garbage collected until the session expires.

    elwolfo said:
    And by then the UltraWebGrid has lost all its rows (and bands).

    To prevent memory leaks, we've added code to most of the grid's sub-objects (including rows and bands) to explicitly dispose them when the page is unloaded.  I believe this was done for either 8.3 or 9.1.  Because of this, the result you're getting is expected.  You'll get the same result with storing a RowsCollection.

    elwolfo said:
    Any ideas?

    First, store the grid's DataSource in session instead.  (If the data is likely to be the same across sessions, you might instead use the cache.)  The data is the most important piece of information that is needed to recreate a grid across postbacks.

    If you need state-related information (such as expanded rows), you'll need to devise your own mechanism for persisting and reapplying that state.

    If I were storing row expansion information in session, for example:  I'd store the DataKey of each row that was expanded at the root band (in case the row moves to a different location due to sorting or to changed data).  Underneath each of those entries, I'd also store the DataKey of any child  rows that are expanded, and so on.  For this type of approach, I'd likely store my data as an XML string in session, to take advantage of its hierarchical nature.  Whatever means you use to store the data, you can read it in the InitiializeRow event of the grid, expanding any rows that match your criteria.  For actually updating this information to track what's expanded and what's collapsed, you'd probably use a combination of client-side and server-side events.

Reply Children