Drunkard's Walk Forums

Full Version: Looking For C#/ASP.NET Help
You're currently viewing a stripped down version of our content. View the full version with proper formatting.
I'm hoping someone here can give me a pointer on a problem I've run into.  I've tried a couple different solutions, none of which have worked; I feel like I'm circling the answer but not quite reaching it.

I'm working with a fairly complex custom control, written by someone else a few years ago.  It's got a couple levels of tabbed panels, a lot of links that either go to new pages or open new windows, several repeaters used to generate tables on the various tabs, stuff like that.  I've added a button to it that, when clicked, is supposed to run some server-side code.  Except it doesn't -- the PageLoad() event for the page on which it displays runs to its end without the control getting a chance to act.

I've figured out that I basically have to turn on the ability for the control to respond to the postback event in its turn.  But I can't figure out -- and my experiments haven't clarified this -- if it's the whole complex control that I need to make postback-aware, or just the button I want to respond to.  Every example of what to do I've found has either slightly or wildly different code that I "should" use.  And perversely, the more complicated the solutions I've found are, the less likely the person writing them is to have a grasp on proper English.

So, I'm hoping a forum member might have a clue what's the right thing to do, and be willing to share that clue with me.
Do you need the button to perform a postback after the client side function, or is it just supposed to perform the client side function and stop? Is there any reason you actually need an asp:Button instead of a simple html input control?
No, it doesn't have to be specifically a button -- in fact, I've just started recoding it as LinkButton to match a few other buttons on the control. Maybe I should reduce it to a simple input.

Also, I made an error in my initial description of the problem -- it's supposed to run code server-side, not client-side -- that will change the answer you might be thinking of.

I've already begun circling in on a solution -- I realized I had to have the overall control (which is a UserControl, not a WebControl) implement IPostBackEventHandler. But I'm still having problems getting it to even notice the postback.
Since it's server side, you should probably still use an ASP button, and yes, server side completely nixed my proposed solution. 

Is the control added dynamically to the page, or is it static? Dynamically added controls do not necessarily have the same ID each time they're instantiated, so if it varies from one postback to the next, then the event handler won't execute. If the control is instantiated outside of the page's Page_PreInit or Page_Init, you likely won't have any saved viewstate values from the postback. You also need to set the event handler each time if the control itself raises an event for the page to handle. If static, then I have no idea why the event handler isn't firing. Also, the Page_Load event (for the page, then the controls) will always run to completion before any event handlers are called.

I've got a couple projects with user controls in them, and none of them implement IPostBackEventHandler.
Yeah, the control is dynamically added to the form, which is indeed one of the problems. But I'm under the gun, so I'm going to give up on trying to do this nice and neat with keeping everything contained and using events and maybe resort to a brute-force solution. I've got something in mind, don't know if it'll actually work, but I'm going to give it a try this morning.

Thanks for the help!
Well, with the advice of a co-worker, I found a solution to my problem. Instead of trying to make this work with an event/handler approach and the IPostBackEventHandler interface, I converted my server-side code to a webmethod which I'm calling with jQuery's $.Ajax() function. It works, and revealed a bug or two I need to address now that the big problem is fixed.

NifT, thanks for your suggestions!