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?
elwolfo said:I want to save an UltraWebGrid in a session variable to keep its state
elwolfo said:And by then the UltraWebGrid has lost all its rows (and bands).
elwolfo said:Any ideas?
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.
Alright, I finally worked it out with saving the datasource in sessions instead. Not a very bug to get from a component update though.
Hi, I read your post and looks fine.
But you should be aware of storing a datasource into a session variable, unless you have a powerful server that support the client requests for you pages, because it will take a lot of resources, maybe, only if fits, you can get around this by storing an array instead a datasource, converting by looping thought and passing it to an array, and then storing the array into the session variable.
As I say, this is only a sugestion.
Pablo Orlando M. Huezo said:... because it will take a lot of resources ...
To expand upon this statement - storing WebGrid in Session state will almost certainly require more resources than storing the data source. Storing WebGrid (or any of its parts) in a Session variable is very much an approach we have always recommended against using whenever it came up. With the changes I mentioned earlier in this thread, it's no longer possible. The same results (minus the memory concerns) can still be accomplished without directly storing the grid in session.
I had the same solution running in 8.2, where i saved a WebGrid to session, to print it on another page.I have now succesfully saved the DataSource in session instead.
Unfortunately, im still missing alot of Formatting information. The order of the columns, Which columns are hidden, Column Headers.
alot of information that is either specified in the intial ASP.net page or calculated by various methods.I would like to avoid having to duplicate my logic code and the asp defintions.
Is there an easy property on the webgrid i can save/restore from session?
bordingdata said:Unfortunately, im still missing alot of Formatting information..... Is there an easy property on the webgrid i can save/restore from session?
If you're talking about formatting applied through the page's markup, that will be recreated automatically with each call to the page, until and unless that formatting is overridden in some fashion.
If you're talking about maintaining formatting that you provide a way for the user to change through the user interface, you will need to implement your own process for tracking and reapplying these changes. For whatever process you use, I recommend again using the InitializeLayout event for reapplying any changes.
I am talking about both formatting applied through code and through page markup.
Unfortunately, since im moving the Datasource from one page to another through the Session, i dont have access to the Page Markup or the code, unless i decide to duplicate my code and page markup.
I am hoping to avoid this duplication.
In Ver 8.2, i was able to save the entire Webgrid to the session, and it retained this formatting for mig.I am hoping to find another, easy fix for this problem
Hello,
The experience I've had trying to update from 8.1 to 11.1 has been very very painful. First, I found after many attempts that version utility didn't worked well to make such a change, and that a manual procedure was required.
So I did that change as it is explained here:
http://forums.infragistics.com/forums/t/66205.aspx
... plus other manual changes in order to compile and run it:
Finally it worked and I was starting to feel like 'happy again', but at the final stage I found that the initial developer for this project used that approach to pass UltraWebGrids into session variables and BOOM! Everything was blown into pieces in a bunch of our application's web pages, because this would require too many changes.
So we'll continue using 8.1 version and downgrade our Internet Explorer's client machines from 9 to 8 for the WebCombo to work.
Welcome to the real world of Updating, Internet Explorer changes and unknown consequences.
Sometimes S**t happens.
bordingdata said:Unfortunately, since im moving the Datasource from one page to another through the Session, i dont have access to the Page Markup or the code, unless i decide to duplicate my code and page markup.
My best suggestion is to apply through code any formatting that is shared across multiple pages, rather than using markup. This method should be available to all pages that contain a grid that would use this formatting.
You might instead use an ASP.NET skin to apply these properties. This will require moving and/or copying markup to another file, yet will allow these properties to be set through markup rather than through code.
You could also use a combination of these approaches. Any shared properties that you're currently setting in code can be moved to a helper method, while any shared properties that you're setting in markup can be moved to a skin file.
While the "store the grid in session" approach may have worked from a functional standpoint in 8.2, it will have introduced a memory leak to your application.