If an asp.net control's event's aren't binding, what are the things I should check, in order of likly cause?

So I've got an ASP.NET control with a server form with a bunch of runat="server" with events defined in the markup. However none of the events are fireing when I click the buttons. The postback occurs and in the Page_Load event IsPostback is true.

What should I be checking to see why the events don't fire? What are the most likely reasons as to why they're not开发者_如何学Python being bound?

UPDATE: I've abandoned this code. When I got to the point of having checked everything mentioned here, still haing postbacks occur but no events firing, I've rolled back to a previous stable state and I'm starting again

This is an interesting way of skinning the cat. You are not asking "What did I do wrong", but "what are the likely things that I could have done wrong".

Interesting, because I think it shows that you want to figure it our on your own, but also because I am having a hard time coming up with suggestions, without any kind of a hint. There is an almost unlimited number of possibilities.

If the form posts back, the event fires. I think this is synonmous. If you don't see an event handler being invoked, maybe you are looking at the wrong place.

I find this method useful in such situations. I call it from page_load, and it shows me details about what caused the event to fire, before event handlers are invoked.

    /// <summary>
    /// Find which control caused the post back
    /// </summary>
    /// <param name="page"></param>
    /// <returns></returns>
    public static System.Web.UI.Control 
                 GetPostBackControl(System.Web.UI.Page page) {
        Control control = null;
        string ctrlname = page.Request.Params["__EVENTTARGET"];
        if (ctrlname != null && ctrlname != String.Empty) {
            control = page.FindControl(ctrlname);
        }
        // if __EVENTTARGET is null, the control is a button type and we need to 
        // iterate over the form collection to find it
        else {
            string ctrlStr = String.Empty;
            Control c = null;
            foreach (string ctl in page.Request.Form) {
                // handle ImageButton controls ...
                if (ctl.EndsWith(".x") || ctl.EndsWith(".y")) {
                    ctrlStr = ctl.Substring(0, ctl.Length - 2);
                    c = page.FindControl(ctrlStr);
                }
                else {
                    c = page.FindControl(ctl);
                }
                if (c is System.Web.UI.WebControls.Button ||
                         c is System.Web.UI.WebControls.ImageButton) {
                    control = c;
                    break;
                }
            }
        }
        return control;
    }

You said a PostBack occurs, so have you put some form of break/logging on the event you want to fire and it never gets there?

Have you turned off ViewState by any chance?

I suspect there's something wrong with you controls life cyle.
I highly recommend studying this great diagram on the ASP.Net Page Life Cycle.

Without seeing you code in your control, you could be wiring events or creating controls at the wrong point in the page life cycle and therefore the event you want to fire is created too late to be fired.

The control will appear to work as .Net is still wiring up the ClientSide javascript to do the PostBack.

Show us your code and we should be able to help further.

Further reading that might be helpful:

MSDN: ASP.NET Page Life Cycle Overview

Code would help, but if they are dynamically created, you could be creating them at the wrong stage of the Page Life Cycle? Hard to say without seeing an example though.

What should I be checking to see why the events don't fire? What are the most likely reasons as to why they're not being bound?

1. Dynamic controls that are created and added to the control tree in Page_Load() or later (should be in Page_Init())
2. Binding of events in Page_Load() or later (should be in Page_Init() or from markup)
3. Disabling ViewState on the page or on the control
4. Taking some action early in the page life cycle that disables the event or makes it look like it never happened
5. The event actually is running, you just aren't seeing it because you're looking for some change in the output, rather than using a debugger