I admit, I'm an .NET n00b. Basically what I'm trying to do is I have a page with a text box on it and an image button. On click of the image button I want it to show a view control I have set up. Inside this view control is an image and some text. So this is what I have in my code-behind.
protected void btnSubmit_Click(object sender, ImageClickEventArgs e)
{
string email = txtUnsubscribe.Text;
vwSuccess.Visible = true;
}
Simple right? Well when I click on the button for submit, I get the "Object reference not set to an instance of an object." error message. Where am I going wrong?
Are txtUnsubscribe and vwSuccess both not null? Have you tried stepping through it in a debugger?
Based on the information (which is to say, based on not much), I'd guess you have an issue with the execution order.
Since you have txtUnsubscribe and vwSuccess members, I'm assuming you initialize these somewhere. If they are auto-generated from the aspx templates, then they are initialized automatically before the event handling so that method will never throw a null reference exception.
If the null reference exception is thrown by that event handler, then it must mean that one of these variables is not initialized (which means that at least one of them is not autogenerated from the aspx and instead should be initialized manually). If you are initializing the variables, then you are likely doing it too late in an event like PreRender or Render.
When you click the button in the browser the browser performs a PostBack to the web server. By default at this point the web server re-constructs the page, performs the event handling and then renders it back to the client. It is important to realize that the page isn't maintained on the server between requests.
The order of events during page load/postback can be found from MSDN: http://msdn.microsoft.com/en-us/library/aa719775(VS.71).aspx
Of course if the exception isn't thrown by that event handler, this whole answer is likely to be wrong and there's probably some simpler issue.
Related
I am running into confusing behavior related to async code registered on an ASP.NET page with RegisterAsyncTask, ViewState, and checkboxes, and I need to know exactly when these async-tasks run relative to when ViewState is saved.
I have a few checkboxes inside an ASP:PlaceHolder control. I am reading a record and populating the checkboxes, then I make the PlaceHolder visible.
If all this is synchronous - maybe within Page_Load - all is well.
If this is registered as an async task the following happens:
The checkboxes get populated.
The Placeholder is visible.
On postback, checkboxes cannot be UNCHECKED. That is, if they were initially checked they retain their checked status even if the user unchecked them. It seems like the checkboxes revert back to their initial values. If a checkbox is checked on the client, that makes it! Unchecking doesn't.
This doesn't seem to be a problem with textboxes. I haven't tried other widgets.
I can 'correct' this problem by setting the PlaceHolder to be visible BEFORE I register the async task. I think this is similar to my other question about Grid visiblity:
asp:DataGrid visibility with async?
It's turning out to be very difficult and resulting in confusing code as I try to pull all the visiblity-rules out of async methods.
I see from the ASP.NET page lifecycle that gets saved sometime before OnPreRender. I also think RegisterAsyncTask'd code gets run about the same time. What order does this happen in? If ViewState is saved before my code runs I'm sunk!
Edit: I found some more detail but it is still confusing:
Halfway down this page: http://www.asp.net/web-forms/overview/performance-and-caching/using-asynchronous-methods-in-aspnet-45 it says
"Methods hooked up with RegisterAsyncTask will run immediately after PreRender."
This page: https://msdn.microsoft.com/en-us/library/ms178472(v=vs.85).aspx details the PreRender and SaveStateComplete events but doesn't mention RegisterAsyncTask. I need to experiment to see if its shoe-horned between them.
The ExecuteRegisteredAsyncTasks gives you some more control in when the tasks are being started.
The ExecuteRegisteredAsyncTasks method is automatically called at the
point in the page processing when any registered asynchronous tasks,
if they exist, are invoked for a non-asynchronous page. This automatic
call to ExecuteRegisteredAsyncTasks occurs just before the
PreRenderComplete event.
From PreRenderComplete documentation:
This is the last event raised before the page's view state is saved.
I have created sharepoint 2010 visual webpart in VisualStudio2010 with three user controls (.ascx). I want to dynamically change usercontrol in the webpart by clicking some button at currently loaded usercontrol. The main problem consist in the fact that buttonClick event is handled only after execution CreateChildControls method (where I try to get needed usercontrol using ViewData). Could anyone please help me to solve this problem?
Lee's response is basically right and may work well for you. However, you should not just use __doPostBack and rely that it will be always "magically" there for you. This method and variables mentioned by Lee are internal to ASP.NET and they are not meant to be used directly. Also, if you do not place any postback-ing control on your page this method will actually not be generated and your code calling it would fail.
Luckily, the code to cause and handle a generic postback is very simple. Instead of using built-in event handlers of input controls (which need to be constructed before being triggered - hence the call to CreateChildControls before your handler is called) you would target the postback to the Web Part itself:
public class MyWebPart : WebPart, IPostBackEventHandler {
protected override void CreateChildControls() {
Control clickable = ...; // Create a clickable control.
// Get JavaScript expression to send postback "test" to "this" web part.
var postBack = Page.ClientScript.GetPostBackEventReference(this, "test");
clickable.Attributes["onclick"] = postBack + "; return false";
Controls.Add(clickable);
}
void IPostBackEventHandler.RaisePostBackEvent(string eventArgument) {
if (eventArgument == "test") { // Recognize and handle our postback.
...
}
}
}
The GetPostBackEventReference will generate the necessary JavaScript expression for you. (And actually, just calling it makes the __doPostBack "magically" appear on the page.) The RaisePostBackEvent will be called between OnLoad and OnPreRender. Make sure not to cause child controls be created before that (by calling EnsureChildControls, for example, or by any other means). If you need multiple postback-ing controls the eventArguments parameter will let you differ among them.
You need the postback triggers in your user controls and not directly in the Web Part. I showed it in the Web Part just to keep it simple. You can put the result of GetPostBackEventReference to any control providing you use the right Page and Web Part instances when calling it.
--- Ferda
A way to do this would be have the button call a javascript function that in turn calls the following:
__doPostBack('LoadControl', 'ControlName');
You can then use the server variables __EVENTTARGET and __EVENTARGUMENT to find out which control to load within your CreateChildControls event handler.
I had that problem too.
Add this to the event handler (after executing your code inside the handler)
this.Page.Response.Redirect(HttpContext.Current.Request.Url.AbsoluteUri, true);
Regards,
Pedro
This article states that Page_PreInit should be used to
create or re-create dynamic controls.
For example:
Button button = new Button();
somePanel.Controls.Add(button);
Good. I understand.
However, it also says:
If the request is a postback, the values of the controls have not yet
been restored from view state. If you set a control property at this
stage, its value might be overwritten in the next event.
Huh?
Does this mean that all I should do is create the button, but not set any members of the button?
For example:
Button button = new Button() { CommandArgument="arg" };
somePanel.Controls.Add(button);
Does this mean that setting CommandArgument in this event is incorrect/not recommended/might cause an error/unexpected behavior?
Assuming it is incorrect, this would lead me to think that one would have to do something like this:
protected void Page_PreInit(object sender.....)
{
somePanel.Controls.Add((new Button());
}
protected void Page_Init(object sender.....)
{
foreach(Button button in somePanel.Controls)
button.CommandArgument = "arg";
}
is this the right way?
Finally, in which event should one set dynamic control properties?
There is no single answer for that last question as depending on the nature of the property it may or may not make sense to set a value in a specific method.
If the request is a postback, the values of the controls have not yet
been restored from view state. If you set a control property at this
stage, its value might be overwritten in the next event.
Might is the keyword here. If you consider some properties that may change as a form goes through various states then this is where you have to be careful of what may get overwritten as well as the question of whether or not this is a bad thing as it may be that the updated value should persistent and in other cases the original value may be better such as if someone wants to reset the form to its initial state.
My suggestion would be to do some trial and error to see what works as I can remember working with dynamic controls that could be tricky in some me cases to manage properly.
Hi I just found out that my application was crashing when returning from tombstoning. I was able to target the problem here inside the constructor of my page:
RadPhoneApplicationFrame frame = App.Current.RootVisual as RadPhoneApplicationFrame;
frame.PageTransitionCompleted +=
new EventHandler<EventArgs>(frame_PageTransitionCompleted);
Everytime the app is Re-Activated the RootVisual is setting the frame to null. I'm wondering if there is a casting issue here because before I used this code my tombstoning was working perfectly and I was able to navigate freely throughout the app. Any ideas on what might be causing this? Or maybe a work around?
You should move this code from page constructor to OnNavigatedTo method override in your page. Reason is that RootVisual is probably set in RootFrame.Navigated event handler which is generated after page is constructed, not before (this depends of implementation in your App.xaml.cs).
Of course because OnNavigatedTo method may be runned more that once for a page, you should make sure that PageTransitionCompleted event handler is not assigned two times (just use -= before +=).
Another option is to move this code to App.xaml.cs. This makes sense most to me, because that PageTransitionCompleted event is related to whole app, not a single page.
I'm working on an ASP.NET project in which the vast majority of the forms are generated dynamically at run time (form definitions are stored in a DB for customizability). Therefore, I have to dynamically create and add my controls to the Page every time OnLoad fires, regardless of IsPostBack. This has been working just fine and .NET takes care of managing ViewState for these controls.
protected override void OnLoad(EventArgs e)
{
base.OnLoad(e);
RenderDynamicControls()
}
private void RenderDynamicControls()
{
//1. call service layer to retrieve form definition
//2. create and add controls to page container
}
I have a new requirement in which if a user clicks on a given button (this button is created at design time) the page should be re-rendered in a slightly different way. So in addition to the code that executes in OnLoad (i.e. RenderDynamicControls()), I have this code:
protected void MyButton_Click(object sender, EventArgs e)
{
RenderDynamicControlsALittleDifferently()
}
private void RenderDynamicControlsALittleDifferently()
{
//1. clear all controls from the page container added in RenderDynamicControls()
//2. call service layer to retrieve form definition
//3. create and add controls to page container
}
My question is, is this really the only way to accomplish what I'm after? It seems beyond hacky to effectively render the form twice simply to respond to a button click. I gather from my research that this is simply how the page-lifecycle works in ASP.NET: Namely, that OnLoad must fire on every Postback before child events are invoked. Still, it's worthwhile to check with the SO community before having to drink the kool-aid.
On a related note, once I get this feature completed, I'm planning on throwing an UpdatePanel on the page to perform the page updates via Ajax. Any code/advice that make that transition easier would be much appreciated.
From Dirk to Dirk :-)
What do you mean with RenderDynamicControls? Create and set controls? If this is your intention not ASP.NET is managing your ViewState, but you do. If you fill the controls on every load, you always overwrite the existing ViewState!
If you want to use the ViewState, create your controls in the pages init event and fill them in the load event, but only if the request isn’t a postback. This is necessary, because ASP.NET recreates the ViewState between init and load. And this is also the reason for the two “rendering cycles” you describe. You need the first control creation cycle because ASP.NET can’t restore the ViewState without a proper control set and ASP.NET can’t react proper on your response without it.
Back to your code: In general your RenderDynamicControlsALittleDifferently wouldn’t work - because you create your controls too late in the pages life cycle and you would damage the ViewState by inserting new objects to the control collection. In a similar situation I solved this problem by a redirecting the page to itself (Response.Redirect). In this case RenderDynamicControls would do the job, based on a “little differently situation” after you change your internal state.