Apparently there’s another more serious issue in this July CTP in that Postback values in a Callback are not getting updated properly from the client. If you go this sample:

http://www.west-wind.com/presentations/scriptcallbacks/sample/invoicelist.aspx

you’ll see that there’s checkbox at the top. With beta 2 I had forced that checkbox to be auto-postback so the full form posted back, because in Beta 2 ASP.NET actually didn’t post back. If you check out the traffic generated you’ll see it actually sends data on the querystring. Well it turns out that it too wasn’t working with the original values being sent back, rather than the updated ones.

After Beta 2 calbacks are supposed to POST back their values and that is indeed happening now. But still the postbacks are not returning the newly update form values.  One has got to wonder whether Microsoft is doing this on purpose? But that would be silly, right? We’ll want the user input values to be posted back and bound back to our controls on the callback so we CAN act on these updated values. Why else would you post back all the data on the form otherwise since we can get the static values anyway.

I would expect this to be fixed by the time ASP.NET 2.0 ships but it’s kinda scary to think that this late in the game this behavior still exists…

I'm finding more weirdness with ScriptCallbacks. Looks like Server.Execute() doesn't work properly with Callbacks anymore in the July CTP. The above sample actually uses server.transfer when the checkbox is checked to retrieve the result from another ASPX page and embeds it into a result string that then gets returned to the client, which then renders the results.

This worked fine in beta 2 but fails in the July CTP. I get an empty string result back from the following function:

public static string AspTextMerge(string TemplatePageAndQueryString, out string ErrorMessage)

{

    string MergedText = "";

    ErrorMessage = "";

    // *** Save the current request information

    HttpContext Context = HttpContext.Current;

    // *** Fix up the path to point at the templates directory

    TemplatePageAndQueryString =  TemplatePageAndQueryString;

    // *** Now call the other page and load into StringWriter

    StringWriter sw = new StringWriter();

    try

    {

        // *** IMPORTANT: Child page's FilePath still points at current page

        //                QueryString provided is mapped into new page and then reset

        Context.Server.Execute(TemplatePageAndQueryString, sw,true);

        MergedText = sw.ToString();

    }

    catch (Exception ex)

    {

        MergedText = null;

        ErrorMessage = ex.Message;

    }

    return MergedText;

}

which gets called like this:

string ErrorMessage = "";

string Output = AspTextMerge("InvoiceAbstract.aspx?id=" + eventArgument, out ErrorMessage);

return Output;

It looks like there's some problem with the page rendering process, but only when calling this code within a script callback. The same code works fine in a standard page.

What’s weird is that if I embed a Response.Write(“Test output“) into the resulting page (invoiceabstract.aspx above), that content comes through fine. IOW, the page actually runs just fine but something in the rendering and HtmlTextWriter output is apparently short circuited. Straight Response object access works fine.

No fun this… I wouldn’t bother with this any further, but the damn article is just hosed for the changes now. Grrrr…