I dynamically create some linkbuttons and assign them the same EventHandler:


In the engCat_Click event, it sets a static variable to the value of the LinkButton's ID that was clicked:



The problem is that this variable is only set the second time I click on the button. It seems the EventHandler method is only called the second time the event happens.

Has anyone encountered this kind of problem before, or know what might be the cause?
Thanks!

where is this ("lb.Click += new System.EventHandler(engCat_Clicked);") piece of code located?

without seeing all of the code, i would hazard a guess that it is inside an
if(Postback){
}
section

No it's not in if (Postback), it is just plain in the Page_Load. I have tried adding it in the PageInit as well (another forum suggested this) but no difference. I think it definately has something to do with creating the buttons dynamically, but it's the only way to solve my problem.

I will try pasting some more of my code to make it clearer..

Maybe I should just fire the button event automatically when the page is busy loading? I have run out of ideas...

Sounds like an ASP.NET application? If so, and if you're working with dynamically-created controls, then you're very likely running afoul of the ASP.NET Page LifeCycle.

This article deals very specifically with that issue:

ASP.NET Page Life Cycle and Dynamic Controls

I know this is an old post, but I recently ran into a similar problem involving a linkbutton contained within a dynamically loaded user control inconsistently requiring two clicks in order to reach its Click handler method. Most of the posts I found kept referring people to the page lifecycle, but in the end that had nothing to do with it. The issue was that the controls ID values were being assigned automatically by .NET so they were {ctl001, ctl002, ctl003...} etc. Because the page allowed users to add or remove sections by clicking on linkbuttons, these ID values were capable of changing between page loads. This would cause the dynamically loaded controls to receive different IDs than they had on the previous page load and would result in a screwed up viewstate. .NET could not identify which control went with which viewstate/handler. After I adopted a less dynamic naming method, based on a root string prefix and a numeric suffix based on a database primary key, the issue was resolved. Because my controls were loaded in a pretty deep nest, there was more than one place where a dynamically generated ID could be introducing this problem. So I would reccomend to anybody dealing with this issue, view source in your browser and look at the IDs assigned to your controls. If there are a lot of ctl002, ctl003, ctl004 type of control IDs in your html try to eliminate those by assigning more explicit and static names that will not be affected by the addition or removal of other controls on the page.

Thank you dogTate, I had the same problem.
It actually wasn't the first time I got screwed by forgetting to give IDs to controls.