why some controls must set autopostback property to be true??

[Matthew Louden]

why need to set autopostback property to be true?? I know autopostback event
means to send the form to the server automatically.

I tried checkbox, checkbox list, radio button, and radio button list, and
they all need to set autopostback property to be true, in order to make the
event of the control fires.

I know this is the must, but I dont know why. Please advise!

Thanks!

 

[Jim Heavey]

It is that way because more often then not you want to do
other things on the form prior to taking a trip to the
server and back. Said another way, more often then not
the requirement is not to do something immediately when
the user clicks on the checkbox.

More trips to the server the "poorer" your performance is.

 

[Teemu Keiski]

Because by default they are not such form controls or HTML elements that
would post to the server. Only buttons are such by default. In HTML (if you
check the HTML that results from using these controls) these controls are
such HTML elements that won't cause posting to happen. So by using
AutoPostBack you tell the control, that it should itself cause a postback
when certain action occurs (checking a checkbox, changing a selection and so
on) and as a result this creates proper javascript events and functions to
be used so that postback happens.

To cause an event to happen on the server, you don't necessarily have to
have AutoPostBack=true for that specific control as long as there is some
other control that causes a postback. DIfference here is that when you have
AutoPostBack=true, the control can cause the postback itself without any
extra control (to cause the postback). If control does not have
AutoPostBack="true", it is dependant on other controls, to cause the
postback so that events are raised (on the server).

 

[John Sparrow]

Just as an interesting side-point:

If autopostback is false, and a postback is caused by another control
(say a button), events will be generated both for the checkbox and the
button, yes?

But in most code design this will lead to *two* databindings, since
the normal assumption is that only one event in generated per
postback.

Is there any way to tell which is the *last* control event to be
fired? and do the databind there?

It's almost as if we need a new event handler: AfterOtherEvents()



John

 

[John Saunders]

Just as an interesting side-point:

If autopostback is false, and a postback is caused by another control
(say a button), events will be generated both for the checkbox and the
button, yes?

But in most code design this will lead to *two* databindings, since
the normal assumption is that only one event in generated per
postback.

That's a very false assumption. There will be one event per control which
wishes to raise an event.

Is there any way to tell which is the *last* control event to be
fired? and do the databind there?

It's almost as if we need a new event handler: AfterOtherEvents()

I agree that we need an event for AfterPostBackEventsButBeforePreRender.

 

[Teemu Keiski]

As John explained, one event per control is are raised, and only one of them
is the event caused by a postback. In other words, only one control at a
time can cause a postback.

For example when you have page which has a CheckBox (AutoPostBack=False) and
a Button. In CheckBox's CheckedChanged event's handler is written
Response.Write("CheckBox_CheckedChanged") and in Button's Click
Response.Write("Button_Click")

1. You first check the checkbox
2. Cause as postback by clicking the button.
3. Output on the page is "CheckBox_CheckedChanged Button_Click"

If you don't (un)check the CheckBox and just click the Button, only
"Button_Click" is outputted. It means CheckChanged event is raised as state
of CheckBox changed, but Button's CLick event is raised because Button
caused the postback.

If you change it so that CheckBox has also AutoPostBAck="true", you always
get either "CheckBox_CheckedChanged" or "Button_Click" outputted, but not
both at the same time, because "touching" either of these controls causes a
postback and the event to be raised.

Hope this helped.

--
Teemu Keiski
MCP, Microsoft MVP (ASP.NET), AspInsiders member
ASP.NET Forum Moderator, AspAlliance Columnist

 

[Teemu Keiski]

We will have such event, it is called LoadComplete. ;-)

New lifecycle is (not all are events or phases but shows what's happening)

-Page.DeterminePostBackMode
-Page.PreInit
-Page.ApplyControlTheme
-Page.ApplyPersonalization
-Page.Init/Control.Init
-Control.TrackViewState
-Page.InitComplete
-Control.LoadControlState
-Control.LoadViewState
-Page.ProcessPostData (Control.LoadPostData)
-Page.PreLoad
-Load
-Page.ProcessPostData (Control.LoadPostData) 2nd try
-RaiseCallBackEvent
-RaiseChangedEvents
-RaisePostBackEvent
-Page.LoadComplete
-PreRender
-Page.PreRenderComplete
-Page.SavePersonalizationData
-Control.SaveControlState
-Control.SaveViewState
-Render
-Unload
-Dispose

I haven't marked which happen on postback but I guess it is clear from the
context.

--
Teemu Keiski
MCP, Microsoft MVP (ASP.NET), AspInsiders member
ASP.NET Forum Moderator, AspAlliance Columnist

 

[John Sparrow]

That's a very false assumption. There will be one event per control which
wishes to raise an event.

But I said "The assumption is that only one event is generated per
postback", ie in that situation two would be generated per postback
(for different controls), not two events per control.

I wonder if there are problems with databinding in the form's
PreRender()??

John

 

[John Saunders]

We will have such event, it is called LoadComplete. ;-)

New lifecycle is (not all are events or phases but shows what's happening)

....

Thank you very much for the info. You've made me a happy man!