working around ASP.NET 3.5 control ID generation: Postback events when the controls are created in a different order on subsequent postbacks

Question

I'm working on a commenting system for a website and on each postback a page generates a user control (called ucComment) for every single comment in the database that pertains to this page. Each ucComment has a Respond button that allows you to respond to each individual comment.

I was having a problem with the Respond button not doing anything when I finally realized that every time a new comment was created, the next postback it would offset all the page's control IDs. In other words, when I click on ctl00_Content_ctl00_ctl01_ctl0*7*_lbtnRespond, that control would actually be generated as ctl00_Content_ctl00_ctl01_ctl0*8*_lbtnRespond on the next postback. So the event associated with ctl07 would simply not happen.

While poking around on the web, I read about overriding the ClientID. I thought if I could name the controls the way I wanted to, I could circumvent my problem. http://west-wind.com/Weblog/posts/4605.aspx It looked like a great hack but it doesn't fire events because of the disparity between the generated ID on the page and how the ID was represented in the control tree.

there's even a guy who derived from MasterPage to change the way that the control tree works to get the above hack to work for postbacks: http://www.netquarry.com/index.php/2009/03/master-pages-ajax-and-javascript-10292/ but i fear that there may be untold repercussions.

What should I do to get my commenting system working such that I can respond to a specific comment and have the respond event still fire even if the control is renamed on that postback?

Answer 1

Any chance you could post the server side code used to generate the user controls? And the aspx page that hosts them?

Answer 2

Hi HaterTot, I'm the guy at NetQuarry that worked up the MasterPage-derived class.

I don't know if you've solved your problem or not. I can certainly understand your concern about my MasterPage approach. I was concerned that it might be fragile as well. However, it's been working well now for about a year and half on about half a dozen different web applications that are built on our platform. That said, since they're all built on our platform, they do have certain similarities. The code also continued to work without issue when we moved from .Net 2.0 to .Net 3.5.

Recently however, we did find a that the approach does not work with UpdatePanels and have not been able to remedy the situation. While researching that problem I discovered that .Net 4.0 provides much better control over ClientID's than .Net 3.5 and I suspect that with 3.5 it will be pretty simple to fix this kind of thing. Here's a good article from Scott Guthrie about this:

http://weblogs.asp.net/scottgu/archive/2010/03/30/cleaner-html-markup-with-asp-net-4-web-forms-client-ids-vs-2010-and-net-4-0-series.aspx

Edit: It just occurred to me that in this case your problem might be solved by simply rendering each comment respond button with a unique ID based on the primary key of the related comment record. That way on a postback the ID of each existing button never changes.

Hope this is helpful.

Cam