469,903 Members | 1,912 Online
Bytes | Developer Community
New Post

Home Posts Topics Members FAQ

Post your question to a community of 469,903 developers. It's quick & easy.

Setting event handler during PostBackEvent

Hello all,

Why can't I wire up an event during the "Raise PostBackEvent" stage of a
postback?

Just in case this is the wrong question, the situation:

deep in the bowls of some code-behind loop:

ImageButton A is created (with ID "A"). ImageButton A's click event is
wired to EventHandler E.

When the user clicks the button, page posts back, page_load runs, event
fires all is good with the world.

During Event E,however, I want to run through aforementioned loop again,
re-creating ImageButton A and assigning its click event to Event E
(again) which seems to work just fine. In fact, all my image buttons
re-appear on the page just like I would expect.

The problem happens when the user clicks on the newly created
ImageButton. The page posts back, page_load fires, but Event E is never
raised.

I'm sure this is by design, but I'm not sure I follow. Don't event
assignments make the round trip in the state bag? I would think that,
as long as I wire everything up before SaveViewState/Render, that ALL
object properties would be saved.

Whate have I missed?

Russell

Nov 19 '05 #1
5 1572
If I understand you correctly,you are _adding_ a _new_ imagebutton in
the eventhandler. You should be aware of the fact that you always add a
control for the _current request_ only. That means that you have to
take into account that you _readd_ the control upon every postback, if
you want to be able to handle its events/keep a valid viewstate/etc.

Nov 19 '05 #2
Hi,

if I understood correct what you mean, then basically page framework has
already in that stage determined which controls will raise which events
(postback event, data changed events), and this detection happens just
before Page_load and second time, right after Page_Load (for dynamical
controls added in Page_Load), but before any postback events (as those
events are raised acording to prementioned detection).

So in other words the controls that raises events should be in Controls
collection at page_Load at the latest. Is this the case with your
ImageButtons?

And to reply about ViewState, basically even wiring don't get saved there,
but they need to be done on every request (unless you of course use
declarative syntax and wire events there when compiler manmages this such
that event handlers are always wired)

--
Teemu Keiski
ASP.NET MVP, AspInsider
Finland, EU

"Russell Smallwood" <ru******@themaplegroup.com> wrote in message
news:MP************************@news.giganews.com. ..
Hello all,

Why can't I wire up an event during the "Raise PostBackEvent" stage of a
postback?

Just in case this is the wrong question, the situation:

deep in the bowls of some code-behind loop:

ImageButton A is created (with ID "A"). ImageButton A's click event is
wired to EventHandler E.

When the user clicks the button, page posts back, page_load runs, event
fires all is good with the world.

During Event E,however, I want to run through aforementioned loop again,
re-creating ImageButton A and assigning its click event to Event E
(again) which seems to work just fine. In fact, all my image buttons
re-appear on the page just like I would expect.

The problem happens when the user clicks on the newly created
ImageButton. The page posts back, page_load fires, but Event E is never
raised.

I'm sure this is by design, but I'm not sure I follow. Don't event
assignments make the round trip in the state bag? I would think that,
as long as I wire everything up before SaveViewState/Render, that ALL
object properties would be saved.

Whate have I missed?

Russell

Nov 19 '05 #3
In article <eS**************@TK2MSFTNGP12.phx.gbl>,
jo****@aspalliance.com says...
Hi,

if I understood correct what you mean, then basically page framework has
already in that stage determined which controls will raise which events
(postback event, data changed events), and this detection happens just
before Page_load and second time, right after Page_Load (for dynamical
controls added in Page_Load), but before any postback events (as those
events are raised acording to prementioned detection).

So in other words the controls that raises events should be in Controls
collection at page_Load at the latest. Is this the case with your
ImageButtons?

And to reply about ViewState, basically even wiring don't get saved there,
but they need to be done on every request (unless you of course use
declarative syntax and wire events there when compiler manmages this such
that event handlers are always wired)


Here's the sequence:

Initial Request:

Page_Init (don't care about this at this point)

Page_Load(load my controls including initial set of buttons)

Event Handling (don't care at this point)
Works great Users pushes button and....

2nd Trip

Page_Init(event handlers are wired up)

Page_Load(page is drawn with old buttons)

EventHandling (old buttons are replaced with new buttons and event
delegates are set)
Works great, new buttons appear on the web form and cause postback no
problem. User pushes new buttons and....
3rd Trip

Page_Init(event handlers are wired up - WRONG - despite the fact that
the buttons were added to the controls container on that LAST trip
before the page was rendered, and are renedered properly in the response
stream, the event handler doesn't appear to be connected with the
control)

Page_Load(page is drawn with last set of buttons - This is what I expect
and want)

Event Handling(event handler never fires even thought the button is
pressed on the user's end and causes postback)

</EXAMPLE>

Why? Everything else about the image button get set correctly, the
image, the id, other attributes everything EXECEPT the event handler
property.

Nov 19 '05 #4
In article <11*********************@l41g2000cwc.googlegroups. com>,
wi****@gmail.com says...
If I understand you correctly,you are _adding_ a _new_ imagebutton in
the eventhandler. You should be aware of the fact that you always add a
control for the _current request_ only. That means that you have to
take into account that you _readd_ the control upon every postback, if
you want to be able to handle its events/keep a valid viewstate/etc.


Thank you for your time and reply. I tried clarifying the situation in
a follow-up to another response to my querey. I says:

Here's the sequence:

Initial Request:

Page_Init (don't care about this at this point)

Page_Load(load my controls including initial set of buttons)

Event Handling (don't care at this point)
Works great Users pushes button and....

2nd Trip

Page_Init(event handlers are wired up)

Page_Load(page is drawn with OLD buttons - This is expected)

EventHandling (old buttons are replaced with new buttons and event
delegates are set)
Works great, new buttons appear on the web form and cause postback no
problem. User pushes new buttons and....
3rd Trip

Page_Init(event handlers are wired up - WRONG - despite the fact that
the buttons were added to the controls container on that LAST trip
before the page was rendered, and are renedered properly in the response
stream, the event handler doesn't appear to be connected with the
control)

Page_Load(page is drawn with last set of buttons - This is what I expect
and want)

Event Handling(event handler never fires even thought the button is
pressed on the user's end and causes postback)

</EXAMPLE>

Why? Everything else about the image button get set correctly, the
image, the id, other attributes everything EXECEPT the event handler
property.

Nov 19 '05 #5
In article <MP************************@news.giganews.com>,
ru******@themaplegroup.com says...
Just in case anyone is following this thread here's some closure:

The problem had nothing to do with Page lifecyle and more to do with
control identification.

In my laziness, I was letting the rendering engine autoID my controls
and, for some reason the first time it rendered my ImageButton (the one
i added in the evernt handler for another control) it was giving it an
ID that didn't match the ID corresponding to the event handler (why... I
don't know). The second time around, it would be assigned the proper ID
and hence the on-again off-again problem I was experiencing.

I discovered all this by turning on the page trace and watching the
controls tree values and the PostBack data.

I went back and made sure to give ID's to all the controls in the
control tree that parented my buttons and everything worked perfectly.

Nov 19 '05 #6

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

18 posts views Thread by Christopher W. Douglas | last post: by
2 posts views Thread by John Dalberg | last post: by
1 post views Thread by David Veeneman | last post: by
By using this site, you agree to our Privacy Policy and Terms of Use.