why some controls must set autopostback property to be true?

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!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.
>--Original Message--
>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!
>
>
>.
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).

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

"Matthew Louden" <mattloude@.hotmail.com> wrote in message
news:uwRbhhXrDHA.2584@.TK2MSFTNGP09.phx.gbl...
> 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!
>
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

"Teemu Keiski" <joteke@.aspalliance.com> wrote in message news:<ObolPZarDHA.3612@.TK2MSFTNGP11.phx.gbl>...
> 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).
> --
> Teemu Keiski
> MCP, Microsoft MVP (ASP.NET), AspInsiders member
> ASP.NET Forum Moderator, AspAlliance Columnist
>
> "Matthew Louden" <mattloude@.hotmail.com> wrote in message
> news:uwRbhhXrDHA.2584@.TK2MSFTNGP09.phx.gbl...
> > 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!
"John Sparrow" <jsparrow@.ecclescollege.ac.uk> wrote in message
news:1357b958.0311180342.24a00161@.posting.google.c om...
> 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.
--
John Saunders
John.Saunders at SurfControl.com
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

"John Sparrow" <jsparrow@.ecclescollege.ac.uk> wrote in message
news:1357b958.0311180342.24a00161@.posting.google.c om...
> 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
> "Teemu Keiski" <joteke@.aspalliance.com> wrote in message
news:<ObolPZarDHA.3612@.TK2MSFTNGP11.phx.gbl>...
> > 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).
> > --
> > Teemu Keiski
> > MCP, Microsoft MVP (ASP.NET), AspInsiders member
> > ASP.NET Forum Moderator, AspAlliance Columnist
> > "Matthew Louden" <mattloude@.hotmail.com> wrote in message
> > news:uwRbhhXrDHA.2584@.TK2MSFTNGP09.phx.gbl...
> > > 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!
> > > > >
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 Saunders" <john.saunders at SurfControl.com> wrote in message
news:uRFZQnerDHA.1084@.tk2msftngp13.phx.gbl...
> "John Sparrow" <jsparrow@.ecclescollege.ac.uk> wrote in message
> news:1357b958.0311180342.24a00161@.posting.google.c om...
> > 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.
> --
> John Saunders
> John.Saunders at SurfControl.com
"John Saunders" <john.saunders at SurfControl.com> wrote in message news:<uRFZQnerDHA.1084@.tk2msftngp13.phx.gbl>...
> > 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.

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
"Teemu Keiski" <joteke@.aspalliance.com> wrote in message
news:%233jZ5UgrDHA.964@.TK2MSFTNGP10.phx.gbl...
> 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!
--
John Saunders
John.Saunders at SurfControl.com