tags:

views:

215

answers:

2

I have an aspx page that has a control which serves as a summary for a GridView that is on the same page. When the page loads, it creates the summary control and dynamically creates links and attaches an event handler to it. Here is a snippet:

protected void Page_Load(object sender, EventArgs e)
{  
    LoadSummaries();    
}

LoadSummaries() loops through the DataSet for the GridView and creates the links. Here is a snippet of how I am creating the links and attaching and event handler to them:

LinkButton lb = new LinkButton();
lb.Text = "Dynamic Text goes here";
lb.Click += new System.EventHandler(this.Search);
lb.CommandName = "CommandName";
lb.CommandArgument = "CommandArgument";

When I run the page, it loads everything fine, but I need to click the link twice for it to go into to Search method. On the first click, the page reloads, but it doesn't go into the search method. On the second click, it does go into the search method.

I was curious as to if it was because on the first click, it actually binds the event handler to the linkbutton, but this is happening in Page_Load, so when the page is loaded, LoadSummaries is called which in turn binds the events to the link button, so I am stuck on understanding why I need to click it twice.

+1  A: 

Are you using any complex controls elsewhere on the page that may be injecting controls into your page?

I have had this problem with pages that have certain controls from libraries that inject controls into the page. I'm using a Calendar control which does this. What was happening to me is that when the controls were built by my code, the control IDs all seemed fine, but just before rendering, the toolkit control was injecting new controls which meant that the postback URL for my link button was identifying itself with one Control ID, but the server thought it should have a different control ID.

This caused the event handler to not be matched to the control on the first post back, so the event couldn't fire. The second time, however, the controls had already been injected so my linkbutton had the new control ID in its postback URL, so then the event could fire.

Solution 1: Get rid of the control that injects and causes the problem. Unfortunately, not always an option. I couldn't do this in my case.

Solution 2: Get rid of LinkButton and use a regular link. May not work if your event handler MUST be on that page.

Solution 3: Provide an ID that will not be altered by other controls. (This was the solution for Xaisoft)

Jay S
Yes, there are some more controls on the page. I did specfiy an ID for the dynamically created link buttons and it seems to work fine now. Can you provide an example of how not specifying the ID for the control changes your postback url? Thanks.
Xaisoft
+1  A: 

Jay is right. Since you are not assigning your controls any ID's it is likely that something is changing in your page on the postback that means it can't link the event with a control.

By the way, it's theoretically bad practice to not assign ID's to your controls since it makes any UI-integrative tests (such as Selenium based test suites) break if you ever change your page layout.

womp
How could I see what is actually happening when I don't assign an ID and when I do? Do I just view the page source?
Xaisoft
Yep. ASP.Net generates control ID's automatically if you don't specify them. The automatically generated ID's are based on the order in which they get added to their parent control. If you change the order of creation (such as by inserting or removing other controls), the ID's will be different.
womp