I would like to be able to display a page, but with all controls disabled. The idea is for a user to view a standard page, but not actually interact with the page. Disabling all UI-controls server side is simple enough, but my main concern is an "inventive" user attempting to manually post the form back with fake information. My question is two fold:
Will built in event validation catch the devious activities?
If event validation doesn't catch it, is there a way to globally throw away the postback event (e.g. the button click, not the full life cycle)
No, you can't stop the normal Postback process.
How are you determining if the page should be disabled? Upon Postback use that same check in your button handler. If it's true, then don't save any information.
public void button1_Click(object sender, EventArgs e)
{
if(Page is disabled)
{
return
}
//Do normal save routine
}
Addressing one of your two questions:
If event validation doesn't catch it, is there a way to globally throw away the postback event (e.g. the button click, not the full life cycle)?
One option may be to add a value to the ViewState, and if that value exists on a postback, redirect the user to an error page. A user tampering with the viewstate should be caught. This doesn't meet your wish to throw away only the postback event, but maybe redirecting to an error page after receiving a postback from a page you thought no postbacks were possible from is ok.
if (ViewState["PageSetToReadOnly"] != null)
{
// Redirect to error page.
}
Another option would be to check if it is a postback in the page's PreInit event, and if so, unwire event handlers:
if (Page.IsPostBack)
{
this.Button1.Click -= new EventHandler(Button1_Click);
}
The best way I think to globally cancel the postback is to override this Page method. You can perform whatever logic you need to set the DoNotProcessPostBack during the OnLoad event :
Protected Overrides Sub RaisePostBackEvent(sourceControl As IPostBackEventHandler, eventArgument As String)
If DoNotProcessPostBack = False Then
MyBase.RaisePostBackEvent(sourceControl, eventArgument)
End If
End Sub
sourceControl is the control performing the postback and skipping over the MyBase.RaisePostBackEvent basically nullifies raising the event for it.
Related
I am adding event handlers to a button like this:
btn.Click += new EventHandler(btn_Click);
However the btn_Click function is not being called (never hits the breakpoint in it) and the button just reloads the page. In my past experience, asp buttons usually perform the click code before reloading the page, so how do I get that to happen when the event is dynamically added?
I also set CausesValidation = false, although there's no validation on the page so I don't think that would have influence anyway.
The event handler needs to be bound for every request regardless of whether or not the page is being posted back. The binding of the event handler is lost at the start of each page request. Event handlers for buttons are typically bound in Page_Load.
You have to set event handlers on Load event (or before). If you do it after Load, it won't be executed since by the time the handler for the event is evaluated it won't be there.
Check this msdn article in relation to page life cycle. I think it will help you to understand. See that event handling occurs inmediatly after Load
I have an ASP.NET user control with a button, and I want to add it to the page when the user clicks a button from another user control. I have created an event handler to the first user control to handle it from the page and add the second user control to a page. Everything is working normally, but the button on the second user control doesn't respond to the event.
I place the second control on RadAjaxPanel
Note: When I add the second user control at design time its working fine.
All dynamically created controls should be added by the end of Page_Init (though sometimes you can get away with them added by the end of Page_Load).
If you're only adding them based on a button click event then you've done this in the event handers which fire AFTER Page_Init and Page_Load in the lifecycle - This is why your events don't fire and why it works fine when you add at design time.
This is because when a button is clicked on the second user control - the whole page lifecycle starts again. The page goes through Page_Load and Page_Init first and your control doesn't get loaded here. So, when the page lifecycle handles the "handle postback events" part, the control no longer actually exists, so the event doesn't fire.
Conversely, when you add at design time, the control exists in Page_Init and Page_Load so is able to handle the postback events from the user control because it already exists in the control tree - if this makes sense.
You need to think how you can restructure so they're added by the time Page_Load has finished at the very latest or it won't work. Without code samples or more detail it's hard to suggest exactly how you might do this. One possibility would be to set it visible instead of loading it outright - but if the control does some 'heavy lifting' on load like database hits or API calls then this might not be suitable for you.
I did something similar. What I did was to load some controls dynamically based on a selection from a DropDownList. If you have a method which loads the control for you, let's call it LoadControls(), then you can do something like this:
DropDownList_Click {
ViewState("LoadControls") = true;
LoadControls()
}
By setting the ViewState variable, you can then indicate Page_Load to load the controls on future postbacks:
Page_Load {
if (ViewState("LoadControls") == "true")
{
LoadControls();
}
}
This has the effect of then loading the control on-the-fly when the event first happens, and then at future times in the lifecycle.
I have a requirement to check for a certain condition on postback before redirecting (Response.Redirect) to another page.
Note... I cannot use JavaScript to detect whether or not to confirm (this is also a requirement) :s
Pseudo:
protected void lbtnRedirect_OnClick(object sender, EventArgs e)
{
if (showConfirm)
{
// Set flag for client side
this.ShowConfirm = true;
// Track this event for next postback.
}
else
{
Response.Redirect("somepage.aspx");
}
}
If the showConfrim flag == true, then the client will be show a modal dialog box asking them if they are sure they want to redirect. If the user clicks on "Yes", then the page posts back and the desired effect is that the lbtnRedirect_OnClick event is fired. How would I about tracking the lbtnRedirect event?
Edit:
I have no problem tracking the flag to show the modal (yes JS must be used to show the modal... somethings you just cannot get rid of :)). I should have been more clear.
It is when the user clicks "Yes" to continue the redirect. The page will postback again but needs to know which event to go through.
i.e. Suppose there are 3 onclick events, 1) lbtnRedirect1_Onclick 2) lbtnRedirect2_OnClick 3) lbtnRedirect3_OnClick... each of which does the confirm check.
Each onclick event does the check. So when the user clicks on "Yes" on the modal, how does the page know which event to drop back into?
You can use ViewState if you're in WebForms.
Implement a ShowConfirm property encapsulating ViewState["ShowConfirm"].
In the first postback you'll set ShowConfirm 'true', and this will activate that modal during the render (if ShowConfirm is true, that's setting as visible 'true' some control).
In the next postback, you'll set ShowConfirm 'false' because is 'true', and finally you'll do the whole redirect!
You can use an ajax call from javascript to set the required values.
Since the postback will happen before even the execution reaches to your button click event we need a workaround here, And if you don't need JS as your requirement, so take a look at
Implementing Client Callbacks Programmatically without Postbacks in ASP.NET
This is much like a wrapper for XMLHttp Ajax call IMHO.
You cannot easily create a model form, without javascipt.
One suggestion I would make is to have panels in your page.
Panel one is visible.
On submit one; panel one hides and panel two is visible asking for a confirmation.
On panel two is a confirm button, clicking this button your redirection is performed.
I am dynamically generating controls, and sometimes I want to create a control and have it ignore the viewstate. For example, sometimes the user has clicked a button indicating they want a different form loaded, so the control tree I generate on postback is different from the original control tree. This is fine, except when I call Controls.Add then it tries to load the viewstate form the old controls into the new controls if the control tree structure is similar, and I want them to instead ignore that viewstate(and also ignore the postback values for input controls as well).
Can I do something like set the IDs of the controls or something that would allow me to conditionally prevent them from getting the viewstate/postback data of the previous request?
Edit: If I let the user of the control load the form on demand in postback handler, the postback data is not applied when I call Controls.Add(this really seems like a flaw in ASP.NET, because I would think if you're going to apply viewstate data "after the fact" through Controls.Add, it'd seem you would then apply the postback data automatically as well after the viewstate data is loaded). The real problem I run up against is my control is very dynamic, but the user of my control can't really tell it what to do until their postback handler fires, because one of the things a user can do is select different forms to be loaded via some link buttons. So it's not until the postback handler runs that they know what the uesr requested, and thus can ask my control to load a certain form. So I have to ask them to do convaluted things like saved the formID that identifies the last form to a session variable, and in OnInit they tell my form what the old formID was via a property. My control then loads the form in OnLoad so that it can consume the viewstate and postback data, and later in the programmer's postback handler, they can choose to clear the form and load a different one if they want.
Edit2: FYI Generating IDs for each control unique to the form works great, so I thought I could eliminate the pointless loading of the old form until the programmer requests a form be loaded in his postback handler. But as I mentioned above, what I found was that loading the form after postback data handling has occurred means that data is lost. Whereas viewstate gets loaded via Contorls.Add, playing catch up in the page lifecycle, it seems postback data does not! So it seems I am defeated at every turn.
You're going to avoid problems if you play along with the control lifetime. Basically, whenever you have a control that renders, it's best to ensure that control is recreated on the next postback, even if you aren't going to need it anymore. The first goal of a postback should be to restore the previous state -- only THEN do you make changes to it.
I described it best in this answer:
Wrong state in Server Controls with same ID's when dynamically adding UserControl to UpdatePanel
Giving the controls different ID's would certainly prevent ViewState from being loaded, that would be one way.
You may also be able to manipulate the ViewStateMode property of your controls by setting it to "Disabled". I'm not sure if this prevents it from loading (it definitely prevents them from saving viewstate), but you could try it.
Have you tried just calling controls.clear prior to adding in the new ones?
UPDATE
I'm starting to believe that you are generating the controls at the wrong point in the page lifecycle. What is your flow?
You must be generating dynamic controls on postback in pageload:
protected void Page_Load(object sender, EventArgs e)
{
--Generate Dynamic Controls--
}
You need to do it like:
protected override void OnInitComplete(EventArgs e)
{
base.OnInitComplete(e);
}
protected void OnInit()
{
--Generate Dynamic Controls--
}
protected void Page_Load(object sender, EventArgs e)
{
}
I have a page and a user control — we'll call them Detail.aspx and Selector.ascx.
Let's say the page shows the details of individual records in a database. The user control basically consists of a DropDownList control and some associated HTML. The DropDownList displays a list of other records to switch to at any time.
When the DropDownList fires its SelectedIndexChanged event, I'd like the parent page, Detail.aspx in this case, to handle it. After all, he'll need to know what was selected so that he can appropriately change the URL and the details shown, etc.
To do that, I've done what I usually do, which is also what the top answer says to do in this StackOverflow question:
public event EventHandler DropDownSelectedIndexChanged
{
add
{
MyDropDownList.SelectedIndexChanged += value;
}
remove
{
MyDropDownList.SelectedIndexChanged -= value;
}
}
The above code appears in the Selector.ascx.cs codebehind file.
As a result, on Detail.aspx, I can use it like so:
<cc1:RecordSelector ID="RecordSelector1" runat="server"
OnDropDownSelectedIndexChanged="RecordSelector1_DropDownSelectedIndexChanged" />
So far nothing fancy or surprising.
Here is my problem:
This causes a NullReferenceException when the browser hits Detail.aspx.
Debugging the problem shows that when the page is first hit, the public event I've shown above tries to add the event, but MyDropDownList is null, thus throwing the exception. From what I can tell, the events are added (or attempted to be added) before the Selector user control's Load event fires and thus also before the DropDownList's Load event fires.
Curiously, if I omit the OnDropDownSelectedIndexChanged attribute from Detail.aspx and instead put the following in the Page_Load event in Detail.aspx.cs:
protected void Page_Load(object sender, EventArgs e)
{
RecordSelector1.DropDownSelectedIndexChanged += new EventHandler(RecordSelector1_DropDownSelectedIndexChanged);
}
It works exactly as expected. The events are attached and handled just fine. No problems.
But this means several bad things:
I have to remember not to use the designer to add said event onto my user control
I have to remember not to add the event via attributes when working in source view
Worst of all, as the control's author I need to make sure everybody else using my control knows 1 and 2
So what am I doing wrong? Every example I've seen thus far shows similar usage of exposing child controls' events through a user control.
The reason this works:
protected void Page_Load(object sender, EventArgs e)
{
RecordSelector1.DropDownSelectedIndexChanged
+= new EventHandler(RecordSelector1_DropDownSelectedIndexChanged);
}
and this does not:
<cc1:RecordSelector ID="RecordSelector1" runat="server"
OnDropDownSelectedIndexChanged="RecordSelector1_DropDownSelectedIndexChanged" />
is because the first one adds the handler after the control has been initialized (via the page's Init). The second example gets parsed much earlier and as such the page is attempting to add the handler before the control has initialized.
Due to the nature of the page's life cycle I think you may have to live with adding the event handler in the code-behind. There will be no way to add the handler before the control is initialized because that control will always be null prior to initialization.