I'm using a Sharepoint WebPart to load a UserControl which has a button that does some processing on PostBack. I got a problem: when I click the button for the first time, the data loaded on ! IsPosback gets lost, but this does not occur when I click the button again. I think my problem is explained here: Sharepoint Lifecycle, but I haven't been able to find a workaround.
Any help would be really appreciated.
Additional Info:
I'm using EnsureChildControls on the WebPart's OnLoad event, and loading the UserControl on CreateChildControls.
I was able to fix this by programatically specifying an ID to the User Control.
E.g.:
protected void Page_Load(object sender, EventArgs e)
{
this.ID = "MyUserControlID";
}
More info here: http://bytes.com/topic/asp-net/answers/314816-dynamically-loaded-control-event-only-reached-2nd-postback
protected override void OnLoad(EventArgs e)
{
base.OnLoad(e);
if (ViewState["MyStuff"] == null)
LoadMyStuffAndSaveToViewState();
else
DoSomethingWith(ViewState["MyStuff"]);
}
Related
I made researching about this subject I could not find proper answer.
In my default.aspx page, I have a treeview. Codes are in default.aspx like below:
protected void Page_Load(object sender, EventArgs e)
{
}
protected void TreeView1_SelectedNodeChanged(object sender, EventArgs e)
{
Control ucont;
if (TreeView1.SelectedNode.Value == "Yeni Dönem")
{
ucont = LoadControl("usercontrols/yenidonem.ascx");
PlaceHolder1.Controls.Add(ucont);
}
else
{
ucont = LoadControl("usercontrols/tabloktar.ascx");
PlaceHolder1.Controls.Add(ucont);
}
}
I load user controls dnynmicaly. User controls are have button control. I can not fire user control's button click when I load it dynamcally. How can I solve this ?
Thanks.
First of all, I would not recommend adding control dynamically later than in Page_Load event. Other things to remember is that You should add it on each page load and assign unique ID value the control that does not change between postbacks.
In this case, the easiest way would be to always add both controls to the page and show appropriate one using Visibility property.
If that's not suitable for You, try to move the code from TreeView1_SelectedNodeChanged to the Page_Load event and load appropriate control on each postback until it should be changed to another one.
I haven't tested this, so if You have any issues when using thise answer, let me know in the comments and I'll try to help.
I'm a bit puzzled by the behavior of the default ASP.NET Authentication controls, by its lifecycle to be precise.
In my MasterPage, I added a LoginView Control which displays the nice [Login] or [Logout] links. When I am logged in and click on [logout], I set up the control to perform a redirection to the homepage of the application.
Internally, when a click on "logout" happens, a postback is triggered. The following steps happen (among others of course):
The page that fired the postback is reinitialized
The page that fired the postback is reloaded
The LoggingOut event is fired
The LoggedOut event is fired
The page that fired the postback is PreRendered
The redirection happens
The target page is loaded (LoggedOut.aspx in my case)
On most of the pages, this works fine. But some pages expect some data to be initialized for their rendering to happens correctly. When this loggout postback occurs, the data isn't correctly initialized, but the page is still PreRendered which leads to some... "unexpected behavior" >_<
My question is thus twofold:
Why does this rendering step happens since the page won't be displayed at all?
Is there a way to prevent the rendering to happen?
Thanks a lot.
Tim
PS: here's a small VS2010 sample project showing you the call sequence & page lifecycle if you want to try it out for yourself http://dl.dropbox.com/u/11764136/LoginTest.7z
There is a way to prevent the actual rendering of the page.
Stop processing the current request when you redirect the page. This can be done by giving a true parameter to the Response.Redirect method:
Response.Redirect("http://somewhere", true);
You can also do this manually by calling Response.Close();
Are you using if(!isPostBack) test to control what should be rendered/re-initialized and what shouldn't?
Venemo's answer gave me an idea that seems to be working.
Instead of relying on the LoginStatus component to perform the redirection, I registered the MasterPage hosting the LoginStatus components to the LoginStatus.LoggedOut event and fire the redirection "per hand" before the PreRender step can be called.
protected void Page_Load(object sender, EventArgs e)
{
MasterLoginStatus.LoggedOut += new EventHandler(OnUserLoggedOut);
}
private void OnUserLoggedOut(object sender, EventArgs e)
{
Response.Redirect("~/LoggedOut.aspx", true);
}
I was concerned the LoginStatus component might remain dirty by doing this but sofar I haven't found any issue with it e.g. "works until proven otherwise".
Remains the question of "why the component behaves like this" but I guess it was a design decision that will remain unanswered.
Edit: this works fine until you get the same problem for the "login" action. Haven't found a way around this one yet.
I've got a serious problem with a DevExpress control (The report DocumentMap) which sometimes requests the whole report, bypassing the caching mechanism, when the end-user clicks on the logout link on the LoginStatus control. I've tried a lot of approaches to stop dead the "logout" postback so that the report won't get generated (some reports took 5 minutes to render, so the logout action sometimes took that long). I think this is similar to your problem: you don't want to do any heavy processing if the user is logging out. So I've tried a different approach: why didn't I recognize that the postback is indeed a logging out postback? All my pages inherit from a base page, so I've set this code in the base page:
public bool IsLoggingOut { get; private set; }
protected override void OnPreInit(EventArgs e)
{
base.OnPreInit(e);
var eventTarget = Request.Params.Get("__EVENTTARGET");
IsLoggingOut = eventTarget != null && eventTarget.Contains("HeadLoginView$HeadLoginStatus");
}
Now all I need to do in my page is to surround any heavy processing with a test of !IsLoggingOut... You could even do you redirect to the LoggedOut page without having to handle any events, just like this:
protected override void OnLoad(EventArgs e)
{
if (IsLoggingOut)
Response.Redirect("~/LoggedOut.aspx", true);
}
Even if you prefer to use the event handler to do that redirect, being able to know that the postback is indeed due to a logout click is a nice thing!
In my case, I was having this problem with the LoginStatus control. I can't see why it is a useful design to post back and Render the page when the user has clicked "logout". Through some tests, I found that I had to let the page go through its entire lifecycle, so Reponse.End() and Response.Transfer() did not work.
My solution was to add event handlers for the LoginStatus LoggedOut event, and then override the Render() method in the master page to do nothing if the user has logged out. I actually had the LoginStatus nested inside a user control that was then in the master page, so I had to bubble the event.
In my user control containing the LoginStatus control, I added an event handler for the LoggedOut event. In the UserStatus.aspx file:
<asp:LoginStatus runat="server" ID="loginStatusDefault" OnLoggedOut="loginStatusDefault_LoggedOut" ... />
Then in the code-behind:
public event EventHandler LoggedOut;
protected void loginStatusDefault_LoggedOut(object sender, EventArgs e)
{
if (this.LoggedOut != null)
this.LoggedOut(sender, e);
}
Now in the master page default.master, I have already included the UserStatus control:
<c:userstatus ID="ctlUserStatus" runat="server" />
and in the code-behind:
protected void Page_Init(object sender, EventArgs e)
{
ctlUserStatus.LoggedOut += ctlUserStatus_LoggedOut;
...
}
bool IsLoggedOut { get; set; }
void ctlUserStatus_LoggedOut(object sender, EventArgs e)
{
IsLoggedOut = true;
}
protected override void Render(HtmlTextWriter writer)
{
if (!IsLoggedOut)
base.Render(writer);
}
For me, the page rendering is what was bombing out when the user clicked "logout", so this took care of the problem for all pages.
What I did was have the logout link or onloggingout control just redirect to another page, "Logout.aspx" which then handles the log out code. Works great actually.
protected void LoginStatus1_LoggingOut(object sender, EventArgs e)
{
Response.Redirect("~/Logout.aspx");
}
I've written a custom widget to allow a user to select a location from a database of locations. This is my first ASP.net custom control. It seemed like everything was working fine, but now there's a problem.
My control implements the RaisePostBackEvent function as follows:
public void RaisePostBackEvent(string eventArgument)
{
SelectedLocationId = eventArgument.Split('|')[0];
SelectedLocationDescription = eventArgument.Split('|')[1];
}
I wrote a test page and included the following in my ASP code:
<%= locationSelector.SelectedLocationId %>
That worked fine.
However, in my web application, the following code does not work:
protected void Page_Load(object sender, EventArgs e)
{
if (Page.IsPostBack)
Response.Write(locationSelector.SelectedLocationId);
// SelectedLocationId is null here!!!
}
When I run this code in the debugger, I see that my Page Load event fires before the Post Back event! Therefore, the data is not yet read from the postback. I know that using the MS provided text field control, the text is available at Page Load, so I think I must be doing something wrong.
How can I read the location that the user selected when the Page Load event fires? To clarify, I'm refering to the Page Load of a web application page.
You're setting SelectedLocationId on a postback event and at the same time you are trying to retrieve its value on the first load. SelectedLocationId will be null all right.
Try:
protected void Page_Load(object sender, EventArgs e)
{
if (locationSelector != null)
Response.Write(locationSelector.SelectedLocationId);
}
I have a user control, which is added to another user control. The nested user control is built up of a GridView, an image button and a link button. The nested user control is added to the outer control as a collection object based upon the results bound to the GridView.
The problem that I have is that my link button doesn't work. I click on it and the event doesn't fire. Even adding a break point was not reached. As the nested user control is added a number of times, I have set image button to have unique ids and also the link button. Whilst image button works correctly with its JavaScript. The link button needs to fire an event in the code behind, but despite all my efforts, I can't make it work. I am adding the link button to the control dynamically. Below is the relevant code that I am using:
public partial class ucCustomerDetails : System.Web.UI.UserControl
{
public event EventHandler ViewAllClicked;
protected override void CreateChildControls( )
{
base.CreateChildControls( );
string strUniqueID = lnkShowAllCust.UniqueID;
strUniqueID = strUniqueID.Replace('$','_');
this.lnkShowAllCust.ID = strUniqueID;
this.lnkShowAllCust.Click += new EventHandler(this.lnkShowAllCust_Click);
this.Controls.Add(lnkShowAllCust);
}
protected override void OnInit (EventArgs e)
{
CreateChildControls( );
base.OnInit(e);
}
protected override void OnLoad(EventArgs e)
{
base.EnsureChildControls( );
}
protected void Page_Load(object sender, EventArgs e)
{
if (IsPostBack)
{
CreateChildControls( );
}
}
protected void lnkShowAllCust_Click(object sender, EventArgs e)
{
this.OnCustShowAllClicked(new EventArgs ( ));
}
protected virtual void OnCustShowAllClicked(EventArgs args)
{
if (this.ViewAllClicked != null)
{
this.ViewAllClicked(this, args);
}
}
}
I have been stuggling with this problem for the last 3 days and have had no success with it, and I really do need some help.
Can anyone please help me?
My LinkButton wasn't firing it's Click event, and the reason was I had its CausesValidation property set to True. If you don't want the link to validate the form, be sure to set this to False.
Try adding your click event to the linkbutton tag:
<asp:LinkButton runat="server" OnClick="linkShowAllCust_Click" />
Or adding it to your Page_Load:
Page_Load(object sender, EventArgs e)
{
this.lnkShowAllCust.Click += new EventHandler(this.lnkShowAllCust_Click);
}
Is the usercontrol within the gridview? If so register the event handler on the gridview's onrowcreated event.
It appears that you have a viewstate issue. Because the control isn't there when the viewstate is loaded the application doesn't know how to hook up the event to be fired. Here is how to work around this.
You can actually make your app work like normal by loading the control tree right after the loadviewstateevent is fired. if you override the loadviewstate event, call mybase.loadviewstate and then put your own code to regenerate the controls right after it, the values for those controls will be available on page load. In one of my apps I use a viewstate field to hold the ID or the array info that can be used to recreate those controls.
Protected Overrides Sub LoadViewState(ByVal savedState As Object)
MyBase.LoadViewState(savedState)
If IsPostBack Then
CreateMyControls()
End If
End Sub
I had the same issue. I had viewstate="false" on the page I was adding the control to. (on the aspx page)
I'm using DotNetNuke 4.9.2 and am running into an odd issue.
I have a MultiView in the module that I'm developing, and in one of the views have a GridView that is bound to an ObjectDataSource.
In a separate view, i have several buttons that will switch the SelectMethod of the ObjectDataSource in the 2nd view and then set that view active. That all works fine, until the grid is sorted on the 2nd view - which causes a postback and the ODS somehow picks up its original SelectMethod. The SelectParameters that are assigned at the same time in the code-behind stick though.
Seems to me that the ObjectDataSource should be remembering the SelectMethod in viewstate, shouldn't it?
<asp:ObjectDataSource runat="server" ID="MyObjectDataSource" SelectMethod="MyFirstSelectMethod" TypeName="Whatever"></asp:ObjectDataSource>
protected void Button1_Click(object sender, EventArgs e)
{
MyObjectDataSource.SelectMethod = "MyNewMethod";
// more code here to change the parameters as well...
MyMultiView.SetActiveView(MyView2);
}
When I run that button click, the grid displays as expected. When I click on one of the column headers for the GridView and break in the page load to inspect the SelectMethod, it has reverted to the one declared in the markup.
Any suggestions as to what my problem could be here?
I'm guessing you've made sure that you're not resetting .SelectMethod when the page reloads?
I ended up working around the issue by just using a page property to hold the selectmethod, and then resetting it on each postback...
protected string MySelectMethod
{
get
{
return (string)ViewState["MySelectMethod"] ?? MySearchResultsDataSource.SelectMethod;
}
set
{
ViewState["MySelectMethod"] = value;
MySearchResultsDataSource.SelectMethod = value;
}
}
protected void Page_Load(object sender, EventArgs e)
{
if (IsPostBack)
{
MySearchResultsDataSource.SelectMethod = MySelectMethod;
}
}
protected void MyButton_Click(object sender, EventArgs e)
{
MySelectMethod = "MyNewMethod";
}
Still not sure why that SelectMethod prop doesn't stick on a postback in nuke. I'm sure this has worked fine for me in straight asp.net projects in the past...