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
240
Selected rows in UltraWebGrid lost on asynchronous postback
posted

I'm using the UltraWebGrid 2009 v1, it has AJAX enabled (browser="xml" and loadondemand="xml).  The grid and other controls are in an update panel.  I'm using _doPostback to force an asynchronous postback, and I don't see any selected rows in the grid on the postback.  I'm fairly certain that this was working before I upgraded from 2008 v2 to 2009 v1.  Has any one else experienced this behavior?  Any thoughts on how to approach finding out why this functionality does not work any more?

Parents
No Data
Reply
  • 45049
    posted

    When the AJAX functionality of WebGrid is turned on, the grid does not maintain information about its rows on the server.  When a postback is performed, the first set of rows (as defined by the DisplayLayout.RowsRange property) are recreated from scratch.  As a result, the grid's selected rows are cleared.  This applies for most load-on-demand types available to WebGrid; if you've set the grid's DisplayLayout.XmlLoadOnDemandType property to Accumulative, the grid rows are instead maintained from postback to postback.

    I suspect that you'll see the same behavior when you take the UpdatePanel out of the equation.  I recommend doing this anyway.  The AJAX functionality of WebGrid is built on our own CallbackManager framework, while UpdatePanel is built atop of Microsoft's ASP.NET AJAX Extensions framework.  These two AJAX frameworks are not compatible with each other, so you may see undesired results when trying to use them together in thsi fashion.  If needed, you may be able to replace UpdatePanel with our WebAsyncRefreshPanel (WARP) to get similar functionality.  Another option is to turn off the grid's AJAX functionality altogether.

    While I'm fairly certain that this is correct functionality, the fact that you recall this behaving differently in an earlier version of the toolset means that this need further research.  I see that you've already logged case number CAS-30406-MQ01Z4 for the same issue, so Developer Support will investigate further through that case.

Children
No Data