This is a migrated thread and some comments may be shown as answers.

2010Q1 Grid collapse more than one group?

6 Answers 70 Views

Grid

This is a migrated thread and some comments may be shown as answers.

6 Answers, 1 is accepted

answered on 17 Mar 2010, 04:12 PM

Maybe we can head this off early : With Ajax it seems that the grid will refresh to defaults on every postback unless directed otherwise. When the user expands a single group, all other groups go back to default of closed and then the selected group is opened when the control is re-rendered. Similarly, if the default is to have all groups expanded, a request to collapse one group will default all groups back to expanded and then process the request to collapse that one group.

So, it looks like I need to maintain the state of the grid expand/collapse, as well as sorting, column order, and other factors, so that when we return from postback the grid will always be in the proper state. I've started to code this into my project using the GridSettings class from the following page:
http://www.telerik.com/community/code-library/aspnet-ajax/grid/storing-multiple-grid-settings-in-database-via-profile.aspx

Is that accurate, or is there some other mechanism for saving the grid grouping/soriting state between postbacks?

Thanks!

answered on 22 Mar 2010, 12:47 PM

Hello TonyG,

Basically, the state of the items will be preserved when expanding/collapsing grouped items. This is demonstrated in the following example:

http://demos.telerik.com/aspnet-ajax/grid/examples/groupby/outlookstyle/defaultcs.aspx

Please, let me know if your setup is similar to the one shown above, or if there are other settings/code to take into consideration.

Kind regards,
Yavor
the Telerik team

Do you want to have your say when we set our development plans? Do you want to know when a feature you care about is added or when a bug fixed? Explore the Telerik Public Issue Tracking system and vote to affect the priority of the items.

answered on 22 Mar 2010, 05:38 PM

Thanks for the notes, Yavor. On a web page I have a user control with a grid. Other controls on the page may fire databinding on the grid, so in the page life cycle I'll see the grid in the UC go through many events before the main page completes loading on postback. The page/control event firing order for this scenario is extremely complex - I have created a spreadsheet to map the path through each user interaction and server event. There are seemingly three "cycles" on Ajax postback and it's difficult to figure out where in this process I need to re-work my code for smooth grouping without damaging functionality for the ungrouped grid.

As an example ... I'm leaving out some details here but this may help someone else doing this. I just want to share my confusion about what's happening. This isn't a complete set of details intended to help the diagnosis:

Cycle 1: We get the normal life cycle of PreInit through InitComplete. Then LoadState starts for the postback. While in LoadState the grid gets ItemEvent GridInitializePagerItem and high-level ItemCreated events. That was unexpected. After LoadState there is a ProcessPostData event, and then we go to Cycle 2.
Cycle 2: This begins with PreLoad and Load for the main page but not for the grid as it does on an initial (non-postback) page load. The grid gets no Load or LoadComplete, but it does go through DataBind here. When DataBound is fired on the grid, PageLoad completes for the web page and then PageLoad begins for the grid. I get a trace log that says "Begin ProcessPostData Second Try" - I need to see where that's coming from.
Cycle 3: Now the ChangedEvents and PostBack events start. Here the grid gets a GroupsChanging event and then the other Item events repeat - normal ItemEvent and ItemDataBound events fire, now interspersed with ItemCreated events for GroupHeaders.

I see how the very simple Outlook sample preserves grouping between postbacks but it looks like my grid is going through a refresh on postback and therefore loses the state of which groups are collapsed - so only the latest single collapse is seen after each postback.

My process of trying to figure out what's going on in there is to turn on tracing, create event handlers for every possible event (that's a lot of guess-work), and set Begin/End Trace.Write() statements around base handlers. It's a sloppy way to figure out where to put code but this is helping me to find events that seem to popup out of the normal page/control life cycle. In addition to trying to figure out this one issue, I'd like to find a better way to diagnose this whole class of problem where we need to do something with a grid, don't know where values are being set, and we need to inject code into the right place to accomplish the goal.

If required I'll see if I can package some code and the events that are firing (maybe in a Support ticket), but as always, it's not practical to provide my entire solution for Telerik to diagnose an issue.

Thanks again!

Accepted

answered on 25 Mar 2010, 08:56 AM

Hello TonyG,

Can you please supply some additional details on your setup - how is the grid populated with data? Is the grid rebound at any time? Does the grid, or any containing control call .databind() directly?
Additionally, you can isolate a small subset of the setup/code, and send it to us in a formal support ticket. We will review it and advise you further on the cause of the problem of why the grid does not persist its state.

Sincerely yours,
Yavor
the Telerik team