Hi
I'm currently using a WebGrid in LoadOnDemand mode, and as such need to handle to InitializeDataSource event for every time the page requests further data.
The problem i'm having is that I have a few search fields on the screen, and if the user chooses to modify these search parameters I get a postback. When that happens, the very first thing that happens (prior to Page_Load) is that InitializeDataSource fires. Having read other posts I inderstand why this is necessary, however what I want to do is modify the DataSource and then have the InitializeDataSource fire again to take into account the new data. I've tried several combinations of modifying the datasource outside of the InitializeDataSource event, and whilst it does actually work the displayed grid only shows the pre-modification data (ie. the data that existed when the InitializeDataSource event last fired). If i scroll the grid, it posts back again and gets the new data, which is great but I dont want the users to have to do the scroll to get the new data.
Is there any way to get the grid to reconsider the data once the InitializeDataSource event has fired?
Chris
You can still re-bind the grid later in the page lifecycle.
It's important to note that the grid will need to bind twice. The grid will need to handle InitializeDataSource once with its "original" data source, particularly to handle any changes that may have been made to that data source. Later in the lifecycle (such as a button click), you'd re-set the grid's DataSource or DataSourceID, then call its DataBind() method.
It's also important to note that you'll need to somehow track which data source your grid is bound to, and to re-establish that connection in the InitializeDataSource event. However you store it, the value must be available during the grid's AJAX callbacks so that it can load additional rows on-demand. Implementations I've seen usually involve using Session variables, either to store the whole data source (such as for small DataTable controls) or a string that allows the program to identify what it needs to bind to (such as a table name and/or specific filter conditions). This value needs to be used during the grid's InitializeDataSource event, and needs to be updated whenever the user changes what data source to bind to
InitializeDataSource wouldn't be called again in this scenario. My apologies for not mentioning this in my previous post.
One solution is to encapsulate the functionality you need called in both circumstances into a method, and call that method both from the InitializeDataSource event handler and after you manually re-bind the grid. Another solution is to use a different event, if there's one that makes sense; for example, InitializeLayout may be useful for processes that need to be run as the grid is bound but before any rows are created in the grid, especially for anything that applies to the grid's DisplayLayout, including band and column definitions. Which approach you take will depend on what you're currently doing in InitializeDataSource and whether or not there's a reasonable, other place to do the same tasks.
Thanks for your response.
I can't share the code really with InitializeDataSource because, under normal circumstances i'm binding to a Dataset i'm storing in the Session (otherwise i'd end up with a query to a remote system firing off every time I moved the scroll bar). When I change a value on the form is the only time I want to actually query the remote system.
I do have a workaround in place now, actually I wouldnt mind your comments on whether you think it's a good idea or not. Basically now after I handle the form's changes, I response.redirect the form back to itself. This causes the whole page to reload and therefore process the changes.
What you've described sounds like it should work, particularly since you have the grid's AJAX disabled. (If you want no load-on-demand at all, set the grid's DisplayLayout.LoadOnDemand property to NotSet.)
InitializeDataSource is too early to check for a change in parameters, at least not during the event in which it becomes clear that you need to change the grid's data source. It's a good place to re-apply the most-recently-applied data source conditions on subsequent postbacks, even when you're not using the grid's AJAX capabilities.
Are you calling DataBind() on the grid in your button click, after retrieving the appropriate data and setting the DataSource of yoru grid?
If you need further assistance, can you provide a concise sample that demonstrates what you have so far, and illustrates what you don't have working? If so, I recommend that you submit a support request and attach your sample, so that a Developer Support Engineer can help you directly. There are a number of circumstances that might cause the approach you've described to not work, we'd need more information to be able to ask the right questions, and this type of issue is likely going to require the personalized attention that a support request provides.
Vince,
I am in similar kind of situation, trying to get the ultrawebgrid to rebind without any success. I do not want to do a response.redirect. Here is the scenario:
1. Databinding occurs in InitiDataSource
2. Users can perform query by entering few query params. On postback, I am trying to rebind the data, unfortunately the data is never rebound.
3. I have tried data rebinding in a btnclick handler( which causes the postback) as well as in initdatasource itself(checking for query params)
4. I donot have AJAX enabled grid. I have tried setting loadondemand to every option available.
I am not sure what I am missing here, if you have any thoughts, I will appreciate it.
Thanks,
Sam
Using Response.Redirect() should work in many cases. It will involve more overhead, since the request has to go back to the client only to come back to the server.
There are circumstances where using Response.Redirect() won't work. The one that comes first to mind is if the redirect is called while processing an asynchronous request triggered by either WebAsyncRefreshPanel or UpdatePanel.
I still believe that the best approach is to refactor what you're currently doing in your InitializeDataSource event handler into a helper method. This should be possible even if you're retrieving data from Session state. Doing this will prevent a round-trip back to the client and back to the server.
Although I can't myself think of why it wouldn't be possible to refactor InitializeDataSource into a helper method, there may well be a reason. In this case, using Response.Redirect() might be unavoidable. I can't provide more precise guidance without having access to your code.