locked
RaisePostBackEvent not called when control is in an UpdatePanel RRS feed

  • Question

  • User-2126497664 posted

     I have followed the samples online and successfully called RaisePostBackEvent, but now that I've moved my control inside an UpdatePanel the method is no longer called. Is there something else that needs to be done? Basically I've modified as simply as possible the example found on MSDN: http://msdn.microsoft.com/en-us/library/ms153112.aspx.

     

    Please help!!!

    Wednesday, September 16, 2009 8:52 PM

Answers

  • User-2106054853 posted

     Hi,

    The result is not caused by UpdatePanel but the code in CreateChildControls. What your code rendered is something like below:

     

    onclick="__doPostBack('WebCustomControl12','NewButton');__doPostBack('WebCustomControl12$NewButton','')"

     

    Therefore it's possible that 'WebCustomControl12$NewButton' is sent to server instead of 'WebCustomControl12'. Then ASP.NET thinks button's RaisePostBackEvent method should be called. By setting a breakpoint at Page's RaisePostBackEvent method you can check the value of sourceControl. It's RaisePostBackEvent method will be called.

     protected override void RaisePostBackEvent(IPostBackEventHandler sourceControl, string eventArgument)
            {
                base.RaisePostBackEvent(sourceControl, eventArgument);
            }

    By appending a "return false" could workaround this issue:

    public class WebCustomControl1 : WebControl, INamingContainer, IPostBackEventHandler
        {
            private Button b;

            protected override void CreateChildControls()
            {
                b = new Button();
                b.ID = "NewButton";
                b.UseSubmitBehavior = false;
                b.Text = "Click Me";
                b.Attributes["onclick"] = Page.ClientScript.GetPostBackEventReference(this, b.ID) + ";return false;";
                Controls.Add(b);
            }

            public void RaisePostBackEvent(string eventArgument)
            {

            }
        }

     

    However, a better practise is to hook Button's click event:

     

       public class WebCustomControl1 : WebControl, INamingContainer
        {
            private Button b;

            protected override void CreateChildControls()
            {
                b = new Button();
                b.ID = "NewButton";
                b.UseSubmitBehavior = false;
                b.Text = "Click Me";
                b.Click += new EventHandler(b_Click);
                Controls.Add(b);
            }

            void b_Click(object sender, EventArgs e)
            {
              
            }

          
        }

     

    • Marked as answer by Anonymous Thursday, October 7, 2021 12:00 AM
    Wednesday, September 23, 2009 4:13 AM

All replies

  • User377791177 posted

    Have you registered your control for postback, using RegisterRequiresPostBack();

    Thursday, September 17, 2009 1:13 AM
  • User-2126497664 posted

    Actually, I have tried that (as well as RegisterRequiresRaiseEvent) and neither work. I don't believe that either of those methods are related to this issue though. Here is the control I have:

    public class WebCustomControl1 : WebControl, INamingContainer, IPostBackEventHandler
    {
        private Button b;

        protected override void CreateChildControls()
        {
            b = new Button();
            b.ID = "NewButton";
            b.UseSubmitBehavior = false;
            b.Text = "Click Me";
            b.Attributes["onclick"] = Page.ClientScript.GetPostBackEventReference(this, b.ID);
            Controls.Add(b);
        }

        public void RaisePostBackEvent(string eventArgument)
        {

        }
    }

    Like I said, when I place the control on the page outside an UpdatePanel, it works fine. But as soon as I place it in an UpdatePanel, it no longer calls RaisePostBackEvent and I can't figure out why.

    Thursday, September 17, 2009 11:35 AM
  • User377791177 posted

    FOLLOW THIS LINK AND TEST YOUR CONTROL

    Friday, September 18, 2009 12:42 AM
  • User-2126497664 posted

     I don't mean to sound rude, but I just don't think you are understanding what I need. The code you linked me to is not helpful to my situation. First, as I've stated several times, I need the code to work in an UpdatePanel. Secondly, calling "Page.RegisterRequiresRaiseEvent is not useful and really shouldn't be used in most cases as it will always cause "eventArgument" in the "RaisePostBackEvent" method to be null. Which leads to number three, the clicked child control will never actually call RaisePostBackEvent because it's being overshadowed by the "Page.RegisterRequiresRaiseEvent".

    I do hope that you have other suggestions about how to get RaisePostBackEvent called when the control is in an UpdatePanel, I really need a solution to this and am willing to look at any options.

    (As a side note, the problem in the post you linked could have been much more easily solved by implementing INamingContainer in the original WebControl.)

    Friday, September 18, 2009 1:09 AM
  • User377791177 posted

     I don't mean to sound rude, but I just don't think you are understanding what I need. The code you linked me to is not helpful to my situation. First, as I've stated several times, I need the code to work in an UpdatePanel.

    AFAIK, there are no two ways of designing a control one that works with update panels and the other without updatepanel, updatepanel is just a wrapper which posts back using XmlHttp.


    (As a side note, the problem in the post you linked could have been much more easily solved by implementing INamingContainer in the original WebControl.)

    How and where is that going to help? u mean i don't need to expose any event?

    Friday, September 18, 2009 1:30 AM
  • User-2126497664 posted

    AFAIK, there are no two ways of designing a control one that works with update panels and the other without updatepanel, updatepanel is just a wrapper which posts back using XmlHttp.
     

    I agree that putting it in an UpdatePanel should not make a difference. That's why I'm so frustrated. Here is my control:

        public class CustomControl : WebControl, INamingContainer, IPostBackEventHandler
        {
            private Button button;
    
            protected override void CreateChildControls()
            {
                button = new Button();
                button.ID = "Button1";
                button.UseSubmitBehavior = false;
                button.Text = "Click Me";
                button.Attributes["onclick"] = Page.ClientScript.GetPostBackEventReference(this, button.ID);
                Controls.Add(button);
            }
    
            public void RaisePostBackEvent(string eventArgument)
            {
            }
        }


    Now here is the the first example of the aspx side:

        <form id="form1" runat="server">
            <asp:ScriptManager ID="ScriptManager1" runat="server"></asp:ScriptManager>
            <asp:UpdatePanel ID="UpdatePanel1" runat="server">
                <ContentTemplate>
                </ContentTemplate>
            </asp:UpdatePanel>
            
            <cc1:CustomControl ID="CustomControl1" runat="server" />
        </form>
    


    When I run the above code, RaisePostBackEvent is called and eventArgument is equal to the ID of my button. However, when I move the control like this:

        <form id="form1" runat="server">
            <asp:ScriptManager ID="ScriptManager1" runat="server"></asp:ScriptManager>
            <asp:UpdatePanel ID="UpdatePanel1" runat="server">
                <ContentTemplate>
                    <cc1:CustomControl ID="CustomControl1" runat="server" />
                </ContentTemplate>
            </asp:UpdatePanel>
        </form>
    

    RaisePostBackEvent is never called. Putting it in an UpdatePanel shouldn't make a difference but it does. I need the control to be in an UpdatePanel so hopefully there is a solution out there that will work for me.

    Friday, September 18, 2009 1:52 AM
  • User-2126497664 posted

     

    How and where is that going to help? u mean i don't need to expose any event?

    I made a response to that post you linked earlier. It would probably be easier to just view my response there rather than try and explain it in this thread (since the two aren't really related).

    Friday, September 18, 2009 1:54 AM
  • User377791177 posted

    You wan't to call RaisePostBackEvent without calling RegisterRequiresPostBack, i don't know how's that possible, and how it worked earlier

    Friday, September 18, 2009 2:35 AM
  • User-2126497664 posted

     

    You wan't to call RaisePostBackEvent without calling RegisterRequiresPostBack, i don't know how's that possible, and how it worked earlier

    You seem to be under the impression that the two (RegisterRequiresPostBack and RaisePostBackEvent) are dependant on each other when that's simply not true at all. While registering your control with RegisterRequiresPostBack does cause RaisePostBackEvent to get fired, as I stated before, eventArgument will always be null. You can also get RaisePostBackEvent to be fired without calling RegisterRequiresPostBack (see this example here for proof: http://msdn.microsoft.com/en-us/library/ms153112.aspx).

    Again, as I stated before, Page.RegisterRequiresPostBack is not ideal in most situations (there is ample documentation on the internet to back me up on this one). If you would just create the control I exampled above you would see what I am talking about and understand what I'm saying.

    In my experience there is often more than one solution to a problem and repeatedly attempting a solution that is known to be wrong is never helpful. So please, shashankgwl, until you have a solution that doesn't involve RegisterRequiresPostBack (unless you can find one that works with it), perhaps let someone else provide a suggestion? I don't want to be rude, but I would much rather find a solution to my problem than debate whether or not your method is valid.

    Thanks.

    Friday, September 18, 2009 10:08 AM
  • User-2106054853 posted

     Hi,

    The result is not caused by UpdatePanel but the code in CreateChildControls. What your code rendered is something like below:

     

    onclick="__doPostBack('WebCustomControl12','NewButton');__doPostBack('WebCustomControl12$NewButton','')"

     

    Therefore it's possible that 'WebCustomControl12$NewButton' is sent to server instead of 'WebCustomControl12'. Then ASP.NET thinks button's RaisePostBackEvent method should be called. By setting a breakpoint at Page's RaisePostBackEvent method you can check the value of sourceControl. It's RaisePostBackEvent method will be called.

     protected override void RaisePostBackEvent(IPostBackEventHandler sourceControl, string eventArgument)
            {
                base.RaisePostBackEvent(sourceControl, eventArgument);
            }

    By appending a "return false" could workaround this issue:

    public class WebCustomControl1 : WebControl, INamingContainer, IPostBackEventHandler
        {
            private Button b;

            protected override void CreateChildControls()
            {
                b = new Button();
                b.ID = "NewButton";
                b.UseSubmitBehavior = false;
                b.Text = "Click Me";
                b.Attributes["onclick"] = Page.ClientScript.GetPostBackEventReference(this, b.ID) + ";return false;";
                Controls.Add(b);
            }

            public void RaisePostBackEvent(string eventArgument)
            {

            }
        }

     

    However, a better practise is to hook Button's click event:

     

       public class WebCustomControl1 : WebControl, INamingContainer
        {
            private Button b;

            protected override void CreateChildControls()
            {
                b = new Button();
                b.ID = "NewButton";
                b.UseSubmitBehavior = false;
                b.Text = "Click Me";
                b.Click += new EventHandler(b_Click);
                Controls.Add(b);
            }

            void b_Click(object sender, EventArgs e)
            {
              
            }

          
        }

     

    • Marked as answer by Anonymous Thursday, October 7, 2021 12:00 AM
    Wednesday, September 23, 2009 4:13 AM
  • User-2126497664 posted

     Interesting, that seems to have done it. I guess I missed that little detail. It does explain why when I was debugging the code would run through OnLoad and CreateChildControls twice. Of course it doesn't explain why "return false;" is required when the control is in an UpdatePanel, but hey, it works, so I'm not going to argue. :)

    I do know that using an event handler would be easier, but I need the event "handled" before CreateChildControls and the only way I know of to do so is to use the RaisePostBackEvent. If you have a cleaner/better solution, I'd love to hear it! Thanks!

    Wednesday, September 23, 2009 12:17 PM
  • User1993186009 posted

    I wonder if you ultimately have found the solution for the issue.

    Thursday, November 24, 2011 4:29 AM