A little new to asp.net.
In my main.aspx page i have:
<users:UsersControl runat="server" ID="usersControl" />
In my UserControl page_load i have:
ViewState["test"] = "test";
In my Page_PreRender in main.aspx.cs:
log...(ViewState["test"]); <-- empty
Why dont i see the value on test?
Im guessing here that the ViewState collection is different in the two contexts you have mentioned.
The first is in the context of the control, and the second is in the context of the page, therefore "test" key is not shared between them.
Also, it is not a good idea to expose a controls ViewState beyond the control boundary. For example use properties on the UserControl as the interface to the viewstate, e.g
public string Test
{
get { return this.ViewState["Test"]; }
set { this.ViewState["Test"] = value; }
}
ViewState should be considered an internal implementation detail of the user control.
Then whenever you need to use this property from the page:
this.userControl1.Test = "This Goes Into ViewState";
I've found a similar answer to your question:
.net ViewState in page lifecycle
It's necessary to understand the life cycle, so why don't use Attributes on the UserControl?
Related
control (eg label) changes value when page loads.
before page load, label value is "x"
proceed to load page naturally x is lost at this point, so what is a simple way to store the value from the previous page
load?
It sounds like what you want is a history of previous states of the page, or at least just one previous value. I can suggest a way to do this, but with a caveat: Don't overuse it. You can persist data between posts in ViewState but that data gets written to the page itself. That way when the users posts the form, they're also posting that data back. (More at the end.)
Here's a simple example. First, define some class that contains all of the additional state you want to store:
[Serializable]
public class PageState
{
public string MyLabelPreviousText {get;set;}
}
Then in your code behind:
public partial class MainPage : System.Web.UI.Page
{
private PageState _pageState;
protected void Page_Load(object source, EventArgs e)
{
_pageState = ViewState["pageState"] as PageState ?? new PageState();
_pageState.MyLabelPreviousText = MyLabel.Text;
}
protected void Page_PreRender(object sender, EventArgs e)
{
ViewState["pageState"] = _pageState;
}
When you load the page, you're checking to see if you've already saved your class (in this case called PageState) to the ViewState. If you haven't, you create a new one.
In the PreRender event, after you're done updating the page, you're updating that class with the text of your label and then saving the whole thing to ViewState again. That way the next time the page loads you can retrieve it again.
I'm not sure at which point you want to save the previous text of your label. In this example it's saving the text during the Load event. That way if the text is changed at any point from then on, the value you have saved is the original text of the label. The details may vary depending on what you're trying to do, but this pattern lets you save that sort of custom data without using Session and piling up data like this in memory.
I mentioned not overusing it. If you save some labels, controls, and other data, ViewState probably won't get too large. ASP.NET is already putting the state of every server control there anyway. But if you go really crazy with it then ViewState can get huge. All of that data gets written to the page, and all of it gets posted back to the server with each postback.
It's probably not a huge concern, but be mindful of it. Use Chrome dev tools, Fiddler, or even just inspect your page source to see if that data is getting so large that it might impact performance.
For anyone who isn't familiar, ViewState looks like this in the HTML source:
<input type="hidden" name="__VIEWSTATE" id="__VIEWSTATE"
value="/wEPDwULLTEyMzgxNzgyNDIPZBYCZg9kFgICAQ9kFggCAQ9kFgJmD2QWAgIBD2QWAmYPZBYMA
... etc.
As you can see, it's actually a hidden form input. ASP.NET is placing all of the details of the page's controls in the form so that when you post the form, it can piece all of that together and make sure that the page looks the same after postbacks. That's the reason why when we set up a lot of controls the first time we check if(!IsPostBack()). If it is a postback then we don't need to populate the dropdowns, etc. all over again. They are restored from that ViewState data.
This approach is functionally the same as adding an additional hidden input as suggested in one comment. The difference is that you're using an existing hidden input (viewstate) and if you need to save multiple values you're just making them properties of a class instead of adding more and more hidden inputs.
I'm not sure if this is what you mean without any code samples but I know from memory that in ASP.NET you can access the previous page property like so:
Page lastPage = currentPage.PreviousPage
Which returns the entire Page object. Assuming your label is defined like so:
<asp:label id="myLabel" runat="server" />
Then you can access the text property with:
Label myLabel = lastPage.FindControl("myLabel") as Label;
lastPageVal = myLabel.Text
So ensure that lastPageVal is a static variable, then it will also persist throughout pages.
I've couple of LinkButtons for which I want to manipulate the cssclass property.
Earlier I used each LinkButton individually to change the cssclass and it worked perfectly upon postback. E.g. lnkbtnHome.CssClass = "tab";
But over time the items increased so I thought it could be better way to do it and I decided to use the Listcollection and use foreach loop to do the same.
Below is the code that I'm using currently.
By default (upon page load) the first button is having a different class tabsel and I want to reset the class of all buttons by setting the class to tab. Upon debugging I can see the cssclass getting modified but it's not changing up in the browser.
Am I missing something?
Under Declaration:
static List<LinkButton> lnklist;
Under PageLoad:
lnklist = new List<LinkButton>();
lnklist.Add(lnkbtnHome);
lnklist.Add(lnkbtnSubject);
lnklist.Add(lnkbtnReport);
Upon Postback:
foreach (var lnkbtn in lnklist){
lnkbtn.CssClass = "tab";
}
Never use static fields in ASP.NET!
You:
I used static to avoid losing the items upon postback.
but that's the nature of HTTP. It's a stateless protocol. You should recreate all controls on each postback in the same way as ASP.NET does it. Otherwise you're are vulnerable to various issues since ASP.NET is a multithreading environment. You could store it in the Session, but i would advise against it. LinkButton is a webcontrol which needs to be part of the current page's control collection. This page will be destroyed at the end of it's lifecycle.
Now I have a change to build a web application in asp.net. The style of ASP.net brings me some weird. The hardest problem is that I couldn't save the value of variable after each PostBack event (when we click button). I've see one solution in the question Dynamic User Controls get and maintain values after postbacks but it just only familiar with the value which binding with controls.
Now I think about 2 solutions:
Like the reference question above, I’ll unbind the data when the page PostBack. I’ll save a variable in a Session and in the UnBind method, I’ll reload to variable in session.
Use the ajax Button (not reload all pages): I really want to use this method, but it sounds very easy to be error. I feel very hard to use Ajax control in asp.net.
My code:
public class MainPage
{
//variable
private List<string> lstName;
public MainPage()
{
if (!IsPostBack)
{
lstName = new List<string>();
}
}
}
Now I found a method to save property of Code Behind Page in ASP.NET 4.0.
That's use ViewState["variableName"] variable. When I need to save a property (e.x var ttsHandler), I save it: ViewState["ttsHandler"]=ttsHandler;
When I need to load its value, I have to type casting:
ttsHandler=(TTSHandler) ViewState["ttsHandler"];
But this solution still only useful with well-known Class type (string, int...) because it have to be Serializable. Unfortunately, some property I can't assign its Class Serializable.
Ex: I have to assign a MyThread class (subclass of System.Thread.Threading), and the debugger require project to Serializa System.Thread.Threading class, that's impossible.
Now I have to use another method, that's not so good, is using Session["var"] instead of ViewState. I'll try my best to handle this, and I'm very glad with your help.
If I put a control in a .aspx file like this;
<asp:TextBox ID="protectedTextBox" runat="server">Some info</asp:TextBox>
I get a declared control in the page's .aspx.designer.cs file;
protected global::System.Web.UI.WebControls.TextBox protectedTextBox;
But I'd like to change the access modifier of the control to public. Is there any attribute or similar that I can set to change the access modifier?
Here's why I want to do it. I am trying to have cross-page postbacks work nice and neatly. I have two pages:
FirstPage.aspx
MyTextBox : textbox
MyButton : button, #PostbackUrl=Secondpage
SecondPage.aspx
MyLabel : label
When the user clicks FirstPage.MyButton, I want to write the value of FirstPage.MyTextBox.Text into SecondPage.MyLabel.Text. I could do it with Page.FindControl, but this seems like a poor substitute to casting the previous page as a FirstPage object and referring directly to the MyTextBox control on it. Something like this;
// on the page_load of SecondPage.aspx;
var previousPage = this.PreviousPage as FirstPage;
this.MyLabel.Text = previousPage.MyTextBox.Text;
Is there any way to change the access modifier?
You can just delete the declaration from the designer and put it in your code behind.
The comments around the declaration say to do this.
/// To modify move field declaration from designer file to code-behind file.
One option I've considered is writing a public property which exposes the original page;
public TextBox PublicTextBox { get { return this.MyTextBox; } }
Which would get the job done, but seems hacky.
Steve, exposing that page's controls would make sense if you'd need to manipulate those controls, but in your case you just need to pass some data (that string) to the other handler, so I would expose that and not the control itself.
Is it possible to access an element on a Master page from the page loaded within the ContentPlaceHolder for the master?
I have a ListView that lists people's names in a navigation area on the Master page. I would like to update the ListView after a person has been added to the table that the ListView is data bound to. The ListView currently does not update it's values until the cache is reloaded. We have found that just re-running the ListView.DataBind() will update a listview's contents. We have not been able to run the ListView.DataBind() on a page that uses the Master page.
Below is a sample of what I wanted to do but a compiler error says
"PeopleListView does not exist in the current context"
GIS.master - Where ListView resides
...<asp:ListView ID="PeopleListView"...
GISInput_People.aspx - Uses GIS.master as it's master page
GISInput_People.aspx.cs
AddNewPerson()
{
// Add person to table
....
// Update Person List
PeopleListView.DataBind();
...
}
What would be the best way to resolve an issue like this in C# .Net?
I believe you could do this by using this.Master.FindControl or something similar, but you probably shouldn't - it requires the content page to know too much about the structure of the master page.
I would suggest another method, such as firing an event in the content area that the master could listen for and re-bind when fired.
Assuming the control is called "PeopleListView" on the master page
ListView peopleListView = (ListView)this.Master.FindControl("PeopleListView");
peopleListView.DataSource = [whatever];
peopleListView.DataBind();
But #palmsey is more correct, especially if your page could have the possibility of more than one master page. Decouple them and use an event.
Option 1 :you can create public property of your master page control
public TextBox PropMasterTextBox1
{
get { return txtMasterBox1; }
set { txtMasterBox1 = value; }
}
access it on content page like
Master.PropMasterTextBox1.Text="SomeString";
Option 2:
on Master page:
public string SetMasterTextBox1Text
{
get { return txtMasterBox1.Text; }
set { txtMasterBox1.Text = value; }
}
on Content Page:
Master.SetMasterTextBox1Text="someText";
option 3 :
you can create some public method that works for you
these approach is not so useful but it helps if you just want to use some limited and predefined control
One think to remember is the following ASP.NET directive.
<%# MasterType attribute="value" [attribute="value"...] %>
MSDN Reference
It will help you when referencing this.Master by creating a strongly typed reference to the master page. You can then reference your ListView without needing to CAST.
you can access with the code this.Master.FindControl(ControlID) which control you wish. It returns the reference of the control, so that the changes are effective. about firing an event could not be possible each situation.
Assuming your master page was named MyMaster:
(Master as MyMaster).PeopleListView.DataBind();
Edit: since PeopleListView will be declared protected by default, you will either need to change this to public, or create a public property wrapper so that you can access it from your page.