Detecting UpdatePanel postback Vs regular postback

Probably a stupid question...

Is it possible to detect on the server-side whether or not the request is a full post back or an updatepanel postback?

Reason is I have a couple of controls on the page that are rather database-intensive and if since an UpdatePanel postback causes a full page cycle, if I could detect it I could avoid having those problem doing the db-intensive rendering task.

Thanks!

Ben

Hi Ben,

You can ask the scriptmanager if it's in a partial page postback, see my example in VB

If ScriptManager.GetCurrent(Me).IsInAsyncPostBack()Then'is in partial postbackEnd If

EACH CONTROL has its own events. if you bind the other controls in the page load event, enclose them with:

if not page.ispostback then

end if

the UpdatePanel has its own events where you can work on.

hi,

i don't think there is any method to identify which postback is done. According to my observation both postbacks are same

First to Check if it is AsyncPostback you can use the YourScriptManager.IsAsyncPostBack and to detect which control casued the postback use the YourScriptManager.AsyncPostBackSourceElementID.

Thanks Richard, that worked just fine (I knew that had to be simple!), marked your reply as answer.

Thanks all for your replies too.

Cheers,

Ben

Deserializing derived objects

Hello!

Maybe my question is rather stupid, but I'm just a newbie...

I have some classes derived from class DataObject, for example Account:

public

classAccount :DataObject {...}

and a [ScriptService()] - marked .asmx service with method

[

WebMethod( EnableSession =true )]publicDataObject AddObject(DataObject dataObject )

which passes this dataObject to another .svc service which writes it to database...

I call AddObject method throughSys.Net.WebServiceProxy.invoke(...), passing JavaScript object corresponding to Account class (I mean it has the same fields). If I set the parameter type in AddObject method to Account - everything works fine, it serializes and deserializes correct and passes further as an Account object. But if I try to set parameter type to DataObject - it looks like deserializer cuts all fields that are not declared in DataObject class and doesn't recognize derived object. The dataObject object in this method is pure DataObject, not Account.

I want to handle objects this way because actually I have now something about 10 classes and 10 such methods, and their number may increase. Writing all methods like AddAccount, AddUser, AddQuote and so on looks unhandy for me.

Is it possible for default JavaScriptSerializer to recognize derived objects? Or if I have to redefine it - how could I do that?

Thank you!

I faced a similar problem. The issue at hand is that the module that does the serialization/deserialization will look to the return types and parameters as cues for what it should serialize to / deserialize to , and it doesn't look deeper than that. I ended up doing a fairly hacky work-around to get the code in on time, but at some point I'm probably going to try and figure out a good solution.

A couple thoughts I had, neither of which are tried out. First, I'm aware that you can generate javascript types for nested types of the web service class (seehttp://ajax.asp.net/docs/mref/T_System_Web_Script_Services_GenerateScriptTypeAttribute.aspx) so that's an option, I suppose. Seems like not the best solution in our case, though, as what we're working with aren't logically nested types of the web service. I also considered writing a serializer module that can take the first param as a type argument so that, at the least, you could specify which concrete type you're sending upstream.instead of letting the module map only to the types in the webmethod params.

For XML Serialization (as used in classic 2.0 asmx web services) there is an attribute called XmlInclude which allows you to specify specializations of the actual return type. omly the ones you list with XmlInclude will be taken into account by the XmlSerializer.

I know the script service infrastructure hooks into the classic asmx stuff, but I have no idea if it looks at XmlInclude-s to. You might give it a try ...

-- Henkk