How to manage solutions that don't fit within the ASP.NET page lifecycle

[Epson Barnett]

I'm new to ASP.NET and have run across a problem several times while
working on web apps. I often need to create content dynamically (based
on an event) which contains dynamically created linkbuttons (or other
webcontrols). These linkbuttons have to be created after events are
processed, and so these linkbuttons cannot have handlers added to them
because they are too late in the page lifecycle for the handlers to
register.

An example:

I have a page that displays the results of a database query. The query
is generated by an interface at the top of the page. The bottom of the
page shows the results of that query. Next to each result is a
linkbutton that allows you to delete that item from the database.

The lower part of the page needs to be generated after the event
handlers for the query interface are fired. This means that the lower
part of the page is created too late in the page lifecycle to attach
eventhandlers to included linkbuttons.

I've kludged around it by using regular HTML instead of linkbuttons
and creating an href javascript calling dopostback - then in my
pageload looking at the POST variables and figuring out what was
clicked.

This works, but because it is accessing parts of ASP.NET that aren't
meant to be accessed directly, I'm afraid it will break in future
versions or on newer browsers.

Ideally, I'd like to be able to refresh the page via a postback - so
that page state and the scroll position is maintained and only the
page lifecycle is rerun.

How are other people handling issues like this?

Regards,
Epson

[Epson Barnett]

I discovered my problem. I wasn't assigning IDs to the dynamically
created controls. Assigning IDs makes the controls able to bind to
events even if they are created later in the page lifecycle.