The July CTP of VS.NET changes the ICallbackEventHandler interface by splitting the single RaiseCallbackEvent in Beta2 into two separate events, PrepareCallbackEvent and RenderCallbackResult. So now instead of having to implement a single brain dead methods we get to implement two methods and pass state between them.
If you read my previous post where I created a CallbackEvent class to manage multiple callbacks, this is what this process looks like now with the new interface definition:
public class wwCallbackEvent : Control, ICallbackEventHandler
{
/// <summary>
/// Event hook to allow routing context back to the Page (or other control)
/// for multiple Callbacks
/// </summary>
[Description("Callback event hook fired when the ClientCallback is received. This event allows routing the event into a single class.")]
public event delScriptCallBack ScriptCallback;
/// <summary>
/// Internally accessible EventArgument captured.
/// </summary>
protected string EventArgument = "";
public void PrepareCallbackEvent(string eventArgument)
{
this.EventArgument = eventArgument;
}
public string RenderCallbackResult()
{
if (this.ScriptCallback != null)
return this.ScriptCallback(this.EventArgument);
return "Not Implemented";
}
}
Since the capturing of the EventArgument only happens in the first method the value is captured and stored and then fired along with the event to whoever subscribes to the event. With this little change the samples I posted in the previous post will continue to work as is.
I’m not sure I see the benefit of the two methods. The first call is probably meant to give you a chance to fix up state of the control/page to get everything set, kind of in line with aquiring POST or Viewstate, but I find that of dubious benefit since all that data will also be available in the later call to the RenderCallbackResult method.
Functionally this broke only this one control in my Beta 2 code, so the above fix took care of that. Abstraction is good <g>, especially in this pre-release cycle.