I have stepped through my code, and it stops when the page is fully loaded, as it should. However, their are a few buttons on the page, that I DO NOT see the names of in my code, so I can't discover where to add a breakpoint to, to follow the logical flow. How can I see what is happening, 'behind the scenes' when one of those buttons is pressed?
EDIT---Would this be an applicable scenario to use tracing?
If you add a Page_Load event to the WebForm, you can put a breakpoint there. That event / method will be called every time there is a server-side interaction with any of the controls on the page, followed by the button click (or whatever other interaction is occurring). When on that breakpoint during a PostBack, you can look at the Form["__EventTarget"] value to determine what control is being invoked and the Form["__EventArgument"] may contain additional details on what event is being triggered.
Related
Got a very "Schrodinger's Cat" moment going on right now.
First, some background on my setup. Most of this is probably irrelevant, but, for completeness, I'm providing it. I'm using a .NET 4.6.2 WebForm (.ASPX page) with a MasterPage. The MasterPage is contained within another MasterPage. Within the WebForm I have an UpdatePanel (UpdateMode = Conditional). Inside the UpdatePanel I have another UpdatePanel (also with UpdateMode = Conditional). Inside that inner UpdatePanel, I have a Repeater and a Button. The Repeater is bound during the Page_Load event of the WebForm, and within a !Page.IsPostBack block. The Button has a Click event that accesses the Repeater.Items Collection.
For some reason, when the Button is Clicked, on PostBack, if the Repeater.Controls Collection is accessed at any time before Page_Load, the Collection becomes emptied. I've tried to figure out at exactly what point the Collection is filled on PostBack, but it seems to be happening somewhere inside the System.Web.dll file, and I can't seem to debug inside that (an unrelated, but frustrating issue).
To simulate this, I've done the following:
1) Added an empty handler for the Repeater.ItemCreated event and put a breakpoint within this event
2) Put a breakpoint on the Page_Init event of the WebForm
3) Added a debugger watch for the Repeater.HasControls() method
When the page is first loaded and the Page_Init breakpoint is hit, the Repeater.HasControls() method properly evaluates as false. During the Page_Load event, since this is not a PostBack, the Repeater is bound, and the Repeater.ItemCreated and the Repeater.ItemDataBound events are fired once for each row created in the Repeater.
When the Button is clicked, a PostBack occurs. When the Page_Init breakpoint is hit, the Repeater.HasControls() method again evaluates as false. If I do nothing else, the next event that fires is the Repeater.ItemCreated event, once for each row - this time around, the Repeater.ItemDataBound event doesn't fire, which is normal, since the Repeater is not being rebound on PostBack (and, for that matter, we haven't reached the Page_Load event either way). Next, the Button Click event is evaluated, and it properly loops through the Repeater.Items Collection. All good.
However, if, during this Button Click PostBack Page Init event, instead of simply evaluating the Repeater.HasControls() method, I access the Repeater.Controls Collection - IE, I put a code block that checks Repeater.Controls, I put a watch on Repeater.Controls, or I even just do a quick watch on Repeater.Controls, the Repeater.ItemCreated event no longer fires. When the Button Click event is evaluated and it tries looping through the Repeater.Items Collection, the Collection is now empty.
I've tried everything I can think of to figure out why this is happening, and have had no success. If anyone has any suggestions on more things I can test for, places I can search, or whatever, I'd love some advice.
Thanks in advance!
Okay,
I have this scenario:
There is a user control with an update panel within it. There is a button within that update panel with proper postback trigger being set. The button_click event is also defined well. I need to call a full postback of the parent aspx page once the "button_click" event is completed. Under ideal case, all the form submission events such as postbacks occur before event based methods are executed. This means my page will first be reloaded then the button click event will be executed. I want something like to reverse this operation. First Button_click event execution then one postback after that on the aspx page(this page calls the user control-> and this user control has the updatepanel with button in it).
Any possible way out would be highly appreciated.
I don't think there's a way to change ASP.NET's lifecycle, like the one you described. A (dirty) way of postbacking the parent page is however to put a hidden button on that page, and call it via javascript in the UC. (via ScriptManager.RegisterStartupScript)
There is an issue that I am facing, is to restrict user from double clicking on a command button. What it does is execute twice the code written inside it's click event. I've read many solutions for it, which I find are irrelevant. The command button, they say, should be disable after a click is performed so that user won't be able to perform another click. This will create an issue when an error occur and the code that is written to enable the button didn't execute.
Is there any other way to do it? Please suggest if any one have better option than this.
You could disable it, and put all your code within a try, catch, finally clause, and put the enabling code in finally.
Give it a read.
That way it should always run, exception or not.
I assume that you are referring to WPF, as Windows Forms has a specific double click event which can be disregarded.
Unfortunately WPF does not make a distinction between double clicking a button and clicking the button twice. This means that you have to perform the check to see if the second click occurred too soon to the first click to be regarded.
This could be done by storing the DateTime.Now in a member variable in the button click event handler and if the click occurs within a too short amount of time of the previous click, simply indicate that the button click event was handled and return without doing anything.
There is a web page (call it main) that contains several frames.
The main and all its included frames raise event DocumentCompleted.
The order of those events is: Subframe1, subframe2, subframeX.., main.
What I want is to parse the content of the main and add some handlers on several html elements on it before the user can take any action. (For example button.Click or link.Click). Till now this is possible by waiting the DocumentCompleted and checking the event's arguments for the correct frame.
However, sometimes the included frames happen to take much time to load and the desired event is not raised within a reasonal amount of time. However the page is visible by the user despite the fact that parsing and the addition of the handlers cannot be done.
So the impatient user interacts with the page, which messes up all the work.
Is there a recommended way to parse the page sooner without waiting for DocumentCompleted (as long as the data is there of course) and keep doing it silently (that is: not show a waiting form or popup to the user)?
You can use the 'Navigated' event, look here
I had an interview a week ago and one of the questions was what the difference was between OnInit and Onload in ASP.NET? I had no clue and I don't find any simple answers on the net so can someone explain shortly and simple what the difference is between both? (What I found was that the difference was somehting in the lifecycle).
OnInit (the Init event) happens after all controls have been initialized, but before ViewState tracking is enabled. It's called bottom-up (the Init events for child controls are called before their parent's Init event).
Init is a good place to add dynamic controls to your page or user control (though it's not a requirement). If you can, then those controls will have their ViewState restored automatically during postbacks (see below). It's a risky place to set control properties, though, because they can be overwritten by incoming ViewState. Init is the right place to set ViewStateUserKey, which can help protect your site from one-click attacks. You would also call RegisterRequiresControlState() from there, if you're using control state.
Right after the Init event, each control enables ViewState tracking, so any changes to a control's properties after that will be reflected in ViewState.
The next events at the page level are InitComplete and PreLoad, neither of which is visible at the control level. During a postback, incoming ViewState is restored into controls between InitComplete and PreLoad.
Then comes the Load event, which happens for both controls and the page. Load is called first at the parent level, and then for any child controls. A master page behaves like a control on a page with regard to event ordering.
You need to read up on the ASP.NET page lifecycle.
OnInit happens earlier in the lifecycle - view state changes have not been done yet and tracking of it has not been turned on.
Page_Init is raised before Page_Load. Page_Init is a good place for code that you want executed before you process further such as attaching event handlers to the load event.
it is better not to access controls in this event because you aren't guaranteed they have been created.
The Page_Load is a good place to store code where you initialize values and any controls specific to the page because you know at this point the controls exist and are available.
You will place a lot more code in Page_Load than you will in Page_Init for the majority of your apps
Both these methods of Control class are invoked by ASP.NET. OnInit() method raises the Init event and OnLoad() method raises the Load event.