When a page is posted back, which statement runs after page_load is done executing? Without knowing what controls are in the page. This is in VS 2008 debugger.
EDIT: The question is about knowing which event and for which control comes next.
+7
A:
- PreInit
- Init
- InitComplete
- PreLoad
- Load
- Control Events (e.g. ButtonClick)
- LoadComplete
- PreRender
- SaveStateComplete
- Render
- Unload
Rex M
2009-09-28 23:50:50
Wanted to know the event and the control that caused the postback without knowing anything about the controls.
Tony_Henrich
2009-09-28 23:54:25
@Tony you can dig into the form post values ("EVENTTARGET", etc) but that's very fragile. You might be better off describing the actual problem you're trying to solve, and get some fresh perspective on that.
Rex M
2009-09-28 23:56:23
I Want to break into the next statement in the debugger after the close curly brace of page_load
Tony_Henrich
2009-09-29 00:01:41
No, you really don't want to do that. You really want to understand ASP.NET well enough to not thinK this is a good idea.
John Saunders
2009-09-29 00:07:59
@Tony why do you need to do that?
Rex M
2009-09-29 00:09:47
+1
A:
The "next statement" is indeterminate. To put it another way, in the sense of "separation of concerns", it's none of your concern. It's the concern of ASP.NET, but not of individual controls on a page, nor of individual developers debugging a page.
I recommend that you determine what question you really needed answered, and what problem you really needed solved.
Here's an example of "why not": Consider the DataBinding event, which is raised when the Control.DataBind method is called, often from inside of Page_Load. Consider a page that contains a DataGrid control. When Control.DataBind is called, the DataBinding event is raised for the control, and Control.DataBind is then called on each control in Control.Controls, eventually causing DataBinding to be raised for those controls. When it gets to the DataGrid, the control will populate its Controls collection with one row for each row in the input data.
Each of the added controls will need to "catch up". They will go through the PreInit, Init, Load, etc. phases - everything up to DataBind.
There's no way to know ahead of time which controls will be added, so you certainly can't determine which events will be fired, and in which order. In fact, some of the control events will fire or not depending on the previous state of the controls. A SelectedIndexChanged event on a dropdown control in a template column of one of the rows may fire if the dropdown index has changed from the last postback, but not if it has stayed the same!
John Saunders
2009-09-29 00:10:54
I want to step through the different events even if their sequence is indeterministic. The runtime has to know what event is next to run when the currentone is done.
Tony_Henrich
2009-09-29 00:32:10
@Tony if you want to step through the events in order to understand what and when things are fired, you won't be able to through the debugger without the ASP.Net runtime .pdbs which, to my knowledge, aren't available. This means the only way to figure this out would be to open up some of the classes using Reflector and visually look at them w/o the debugger. Now if this is a NEED and not a WANT, you may have other issues and, like others have said, should probably say why you NEED to step into these events.
JamesEggers
2009-09-29 01:10:04
@Tony we'd love to work with you on the actual problem you're trying to solve. What you're asking for is extremely difficult and would require a great deal of work to only get you further down a bad path. If we can talk about the problem that started this line of questioning, I bet we can work with you to find another solution that's far less effort and gets you much further.
Rex M
2009-09-29 01:38:17
Tony, why would you want to step through the events when the next time, they'll be called in a different order, even if they're called at all. And it's not true that the runtime must know the next event before the current one is "finished" - it may very well determine the "next" event _after_ the current one is finished, and this determination will often depend on what happens during the current event. You're way off base here, asking for the wrong thing. Tell us _why_ you want to know, and we can help.
John Saunders
2009-09-29 02:04:58
Runtime has to execute the events. Maybe not the same order every time but it will execute the event until none are in the queue. So why why can't the debugger do the same? I just want to follow what the runtime is doing. Once an event is done, another something in my code will run. I just want to step into it.. I don't care what event sequence is taken at the time.
Tony_Henrich
2009-09-30 00:37:12
Tony this isn't the "ASP.NET debugger". It's the .NET debugger. It has no special intimate knowledge of ASP.NET implementation details. Why would it be able to "read the mind" of ASP.NET to know about events that are going to be raised before they are raised? Why would it know which methods will be called when the events are raised? Why do you assume that only your code will be run? And you might try to answer what we've been asking you: why do you want to do this? The fact that you want to do this is the problem that needs correction.
John Saunders
2009-09-30 00:59:53
A:
You need to get a copy of the ASP.NET runtime .pdbs if you want to debug the ASP.NET runtime, good luck. :)
rick schott
2009-09-29 01:02:29
Yes, you do, since it's the runtime that orchestrates event execution.
John Saunders
2009-09-30 01:00:33