2

I have been scratching my head on this one for a few hours now and the issue seems to be interesting. I seem to be missing the __doPostBack event that should come with my control but it does not. Some have suggested adding:

ClientScript.GetPostBackEventReference(this, string.Empty);

this however, while it does create a function definition I am looking for, no matter what I do the page reloads on the postback event. As some have mentioned in:

__doPostBack is not defined

this is because the control ID does not match/not found.

I am obviously doing something wrong considering that 1) The postback function does not render without being brute forced in 2) Even when brute forced in, the postback cannot find the appropriate setup. Here are the snippets of code:

Class definition

[ParseChildren(true)]
[PersistChildren(true)]
[ToolboxData("<{0}:Accordion runat=server></{0}:Accordion>")]
public class Accordion : DataBoundControl, IPostBackEventHandler

Events

public event JQUI_Event ItemClick;

Click handler, RaisePostBackEvent, and the OnLoad which appends the __doPostBack

    public void RaisePostBackEvent(string eventArgument)
    {
        ItemClick(null, null);
    }

    protected override void OnLoad(EventArgs e)
    {
        Page.ClientScript.GetPostBackEventReference(this, string.Empty);
        base.OnLoad(e);
    }

    protected virtual void OnClick(EventArgs e)
    {
        if (ItemClick != null)
        {
            ItemClick(null, null);
        }
    }

Finally the code which generates the the postback:

        if (ItemClick != null)
        {
            outPut += "<script> $(function() { $('#" + ClientID + "').find('div').on('click', function() { __doPostBack('" + UniqueID + "', '') }); }); </script>";
        }
        writer.Write(outPut);

Let me know if you need more code. I didn't want to just throw a long page of code and just tell people to figure it out.

EDIT:

Ok, got the RaisePostBackEvent(string eventArgument) to get called. However, the issue I am having is that the page still decides to reload. I have tested to make sure that it calls the correct function in the correct control (not just because it's a postback). Is there a way to limit this to a partial postback rather than a full postback?

Community
  • 1
  • 1
Serguei Fedorov
  • 7,763
  • 9
  • 63
  • 94

1 Answers1

1

See the GetPostBackEventReference documentation, which shows it returns a string, which contains the __doPostBack method call. It's not a registration method for the control. You then render this string with your control. The __doPostBack is not an automatic output when you are using custom controls.

Brian Mains
  • 50,520
  • 35
  • 148
  • 257
  • Thanks a lot! I caught onto that when I realized the sequence of events. However, I am wondering why it is reloading my page when all the code runs through. Is it because no elements have been updated (could be if the implementation doesn't need to do anything on the front end) – Serguei Fedorov Jul 31 '13 at 17:06
  • OK, I'm a little confused about what you mean "your code runs all the way through"... could you elaborate on that? – Brian Mains Jul 31 '13 at 19:29
  • Yea no problem. What I mean is that the RaisePostBackEvent is triggered with the correct arguments and from there I call the event handler. After all the code has executed, the page reloads. I am a bit stumped by this. I believe it runs a full postback rather than a partial one. – Serguei Fedorov Jul 31 '13 at 19:31
  • __doPostBack always runs a full postback. That is the correct behavior; the only mechanisms for partial postbacks are: page callbacks (also javascript-based) or using the UpdatePanel – Brian Mains Aug 01 '13 at 00:26