I have a number of pages that use UltraWebGrid with in grid editing. I am trying to find out what page event (if any) occurs before the grids request data but after the page state has been reloaded. On first request the Page_Load seems to be called before the grid_initializedatasource but on postback the grid_initializedatasource is called before the page_load. I tried tapping in the page_initcomplete and page_preload events but those also occur after the grid_initializedatasource. I have a basepage that all my webforms inherit from and I want to create a method in the base page that either captures a businessobject from sessionstate or restores one from an id on a hiddenfield on the page prior to the grids initializedatasource events.
Hello,
The best page to get started with that is here - this great blog post called "Demystifying WebGrid DataBinding" - plenty of useful information there
http://blogs.infragistics.com/blogs/tony_lombardo/archive/2008/01/29/demystifying-infragistics-webgrid-databinding.aspx
You may also find the following ASP.NET page lifecycle MSDN article useful as well (which event gets fired when)
http://msdn.microsoft.com/en-us/library/ms178472.aspx
As far as InitializeDataSource is concerned - yes, this event is called automatically whenever the grid needs data (before displaying, after postback to restore the state, on sorting, etc, etc) - so there is no fixed place in the ASP.NET page lifecycle where it is called. In most of the cases this is exactly what you need, but yes - if you do need better control on that, you may need to databind not in InitializeDataSource, but elsewhere - depending on the logic.
OK thank you. I am familiar with both documents you mentioned but was looking for some place in the page lifecycle that I could tie into after the viewstate was restored but before the grid initializedatasource events, sounds like that does not really exist.
Indeed - if you followed Tony Lombardo's blog post on this event, you would see that at one point there were mixed feelings about InitializeDataSource exactly because of the reason that you mention. We even wanted to deprecate it at one point, but it turns out that in 90% of the cases it does exactly what developers want and is super convenient to use, so we decided to leave it due to popular demand.