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

Discussion in 'ASP .Net Web Controls' started by Matthew Louden, Nov 18, 2003.

  1. 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!
     
    Matthew Louden, Nov 18, 2003
    #1
    1. Advertising

  2. Matthew Louden

    Teemu Keiski Guest

    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" <> wrote in message
    news:...
    > 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!
    >
    >
    >
    >
    >
     
    Teemu Keiski, Nov 18, 2003
    #2
    1. Advertising

  3. Matthew Louden

    John Sparrow Guest

    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" <> wrote in message news:<>...
    > 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" <> wrote in message
    > news:...
    > > 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, Nov 18, 2003
    #3
  4. "John Sparrow" <> wrote in message
    news:...
    > 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, Nov 18, 2003
    #4
  5. Matthew Louden

    Teemu Keiski Guest

    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" <> wrote in message
    news:...
    > 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" <> wrote in message

    news:<>...
    > > 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" <> wrote in message
    > > news:...
    > > > 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!
    > > >
    > > >
    > > >
    > > >
    > > >
     
    Teemu Keiski, Nov 18, 2003
    #5
  6. Matthew Louden

    Teemu Keiski Guest

    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:...
    > "John Sparrow" <> wrote in message
    > news:...
    > > 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
    >
    >
     
    Teemu Keiski, Nov 18, 2003
    #6
  7. Matthew Louden

    John Sparrow Guest

    "John Saunders" <john.saunders at SurfControl.com> wrote in message news:<>...
    > > 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
     
    John Sparrow, Nov 18, 2003
    #7
  8. "Teemu Keiski" <> wrote in message
    news:%...
    > 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
     
    John Saunders, Nov 19, 2003
    #8
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. David Wier
    Replies:
    0
    Views:
    637
    David Wier
    Aug 27, 2003
  2. Matthew Louden
    Replies:
    1
    Views:
    454
    bruce barker
    Nov 18, 2003
  3. Matthew Louden
    Replies:
    8
    Views:
    569
    John Saunders
    Nov 19, 2003
  4. Mr. SweatyFinger
    Replies:
    2
    Views:
    2,137
    Smokey Grindel
    Dec 2, 2006
  5. bdb112
    Replies:
    45
    Views:
    1,403
    jazbees
    Apr 29, 2009
Loading...

Share This Page