How to step into after page_load event with debugger?

[John Dalberg]

I need to know what happens after Page_load has finished so I put a
breakpoint at the last statement. However after stepping into after this
last statement, the app continues running without the debugger. Why can't I
single step until the screen has fully rendered?

 

[Mr Newbie]

There are several events which take place during the cycle of an initial Get
or Postback, here is an explaination from Kevin Spencer the other Day. When
you are stepping though the Page_Load event or any other, you dont simple
step into the next event. You need to set breakpoints in those events. If
you dont have one then the code will continue. This is different from
following code excecution through Subs and Functions when you can choose to
Step In or Step Over function calls.

HTH

Mr Newbie . . .


From Keven Spencer

Upon PostBack, during the *LoadViewState* Event Handler method, the
ViewState is read, to prepare for restoring the Controls that will be
rebuilt to the state they were in during the previous Request.

All of the HTML form field values are read during the *LoadPostData* Event
Handler method of the page, providing the current client-side state of the
Page and Controls in it.

The *Load* method re-creates all of the Controls in the Page (including the
Page), and sets them to the state they were in during the previous Request.

Next, PostBack changes are processed by the Page and Controls in the page,
via the *RaisePostBackChangedEvent* method of the Page. This is where the
data in the form is compared with the PostBack data. Change events are fired
for Controls that have had their state changed, and have event handlers
specified to handle the Change event for those Controls. These events are
also handled at this time.

After that, the* RaisePostBackEvent* method is executed, which handles the
client-side event that caused the PostBack. At this point, the event-related
form field values are read, and an event is created, which is processed by
the affected Control's event handler for that event.

The *PreRender* event is executed next, which handles any additional
housekeeping that may be needed, and any code that the developer has defined
for additional pre-render processing. Sometimes changes must be made after
all of the current changes and events have been processed. This is the app's
last chance to do this.

The *SaveState* method saves the current client state of the Page to the
ViewState.

And finally, the page is *Render*ed to the browser.

 

[Scott Allen]

Since the flow of control leaves your code and goes back into the
runtime code, the debugger isn't smart enough to know what the "next
step" should be....

.... in VS 2003, at least.

VS 2005 has some nifty tricks and will let "step" into the next piece
of your code that executes. This might be the next event on the page,
but it might also be an event in a master page or user controls. It is
smart enough to step through your code, but not enough of a mind
reader to know exactly what code you wanted to go to next.