RaisePostBackEvent not called when control is in an UpdatePanel

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!!!

Re: RaisePostBackEvent not called when control is in an UpdatePanel

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

Re: RaisePostBackEvent not called when control is in an UpdatePanel

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.

Re: RaisePostBackEvent not called when control is in an UpdatePanel

FOLLOW THIS LINK AND TEST YOUR CONTROL

Re: RaisePostBackEvent not called when control is in an UpdatePanel

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.)

Re: RaisePostBackEvent not called when control is in an UpdatePanel

ipshing
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.

ipshing
(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?

Re: RaisePostBackEvent not called when control is in an UpdatePanel

shashankgwl
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.

Re: RaisePostBackEvent not called when control is in an UpdatePanel

shashankgwl
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).

Re: RaisePostBackEvent not called when control is in an UpdatePanel

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

Re: RaisePostBackEvent not called when control is in an UpdatePanel

shashankgwl
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.

Re: RaisePostBackEvent not called when control is in an UpdatePanel

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)
        {

        }

}

Re: RaisePostBackEvent not called when control is in an UpdatePanel

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!

Re: RaisePostBackEvent not called when control is in an UpdatePanel

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