I have a fileupload , in fileupload used onchange event , on change event use a javascript function that call a static webmethd to validate filecontent .
how can i calling masterpage control in this static function in this page
please help me this nessecery
Since the static method has no knowledge of the current System.Web.UI.Page, you might not be able to access the property you are looking for. It's hard to tell what you're trying to do without a code example.
You can try the code below, but it might not work since the view state will not be available via an async WebMethod call. View state is transmitted with each postback and a System.Web.UI.Page object is instantiated using the viewstate. Since you aren't doing a postback, view state is not available.You might have to do a full postback.
If the property is being stored in Session state or Application state you might be fine. Try
Page currentPage = HttpContext.Current.Handler as Page;
currentPage.MasterPage.MyProperty = "foo";
Related
I disabled the viewstate on page and each control within it. But I still see short string representing the viewstate in the page source.
I created a page with two controls, one a checkbox and other a texbox. I completely disabled the viewstate for both the controls and the page. But I still see a div rendered which contains the viewstate in the hidden variable:
<div class="aspNetHidden"> <input id="__VIEWSTATE" type="hidden"
value="/wEPDwUKMTcwNTQzMjY4MWQYAQUeX19Db250cm9sc1JlcXVpcmVQb3N0QmFja0tleV9fFgEFG
2N0bDAwJE1haW5Db250ZW50JGNoYm94VGVzdPRq7jJUwzyCcKYfAFB/seRcAvziSp3bKL23H9U7O9sU"
name="__VIEWSTATE"> </div>
Can anyone help in understanding this behaviour of asp.net
1) You must have a server-side form tag () in your ASPX page if you want to use ViewState. A form field is required so the hidden field that contains the ViewState information can post back to the server. And, it must be a server-side form so the ASP.NET page framework can add the hidden field when the page is executed on the server.
2) The page itself saves 20 or so bytes of information into ViewState, which it uses to distribute PostBack data and ViewState values to the correct controls upon postback. So, even if ViewState is disabled for the page or application, you may see a few remaining bytes in ViewState.
3) In cases where the page does not post back, you can eliminate ViewState from a page by omitting the server side tag.
http://msdn.microsoft.com/en-us/library/ms972427.aspx
It's the control state.
If you really want to get rid of viewstate and controlstate you can use this code in the code-behind for the page, or in any class that the code-behind derives from
class MyPage : Page {
private class DummyPageStatePersister : PageStatePersister {
public DummyPageStatePersister(Page p) : base(p) {}
public override void Load() {}
public override void Save() {}
}
private DummyPageStatePersister _PageStatePersister;
protected override PageStatePersister PageStatePersister {
get {
if (_PageStatePersister == null)
_PageStatePersister = new DummyPageStatePersister(this);
return _PageStatePersister;
}
}
// other stuff comes here
}
Be very careful when doing this, though, since you're violating the contract with the controls. MSDN explicitly states that control state is always available. In practice, however, it has worked for me.
Edit:
Since I was downvoted, I like to point out again: Don't do this unless you know exactly what you are doing. In my case, almost the entire application was written in client-side javascript, and on those few occations where postbacks occurred, I always used the Request.Form collection to retrieve the values. Do not use server-side controls for anything but simple rendering if you do this.
No, you can not get rid of View State completely. You will always have a relatively short string representing the page itself even if you turn off the view state on each and every control.
Check State Management (View State).
I stored a object in viewstate on Page. Now when i access the same viewsate object on usercontrol,it shows as null. I even tried creating the same viewstate with same name in usercontrol and page.Both holds different value.
I understand that viewstate is a protected property. How does this thing implement in above scenerio or is there any other reason for this behaviour.
Edit:
Usercontrol is there in the page markup. I am not loading it dynamically.
I have a page EditFacilityworkType.aspx. On page I have a usercontrol FacilityWorkTypeDetails.aspx(FacilityWorkTypeDetails1). Inside this usercontrol i have a user control Workflow.aspx(Workflow1)
Page_Load() of Page
I am retrieving workflowdetails on page_load() of page.
FacilityWorktype facilityWorkType = facilityDetails.GetFacilityWorktypeDetail(SessionHelper.FacilityWorkTypeID);
ViewState["WorkFlow"] = facilityWorkType.FacilityWorkTypeWorkFlow
Inside usercontrol FacilityWorkTypeDetails.aspx. I have a property
public FacilityWorktype FacilityWorkTypeDetails
{
get
{
#region Fill FacilityWorktype
return GetEntityFromControl();
#endregion
}
set
{
PopulateControls(value);
}
}
Now i set this property in page load of page
FacilityWorkTypeDetails1.FacilityWorkTypeDetails = facilityWorkType;
Inside Workflow.aspx, I have a property
/// <summary>
/// Property to fill entity object from controls on this page
/// </summary>
public WorkFlow WorkFlowDetails
{
get
{
return GetEntityFromControls();
}
set
{
BindTranscriptionMethodDDL(ddlTranscMethod);
PopulateControls(value);
}
}
Now PopulateControls() of FacilityWorkTypeDetails1, i am setting property of workflow1
private void PopulateControls(FacilityWorktype value)
{
Workflow1.WorkFlowDetails = value.FacilityWorkTypeWorkFlow;
}
Now when i am retrieving values from
private WorkFlow GetEntityFromControls()
{
WorkFlow workFlow = (ViewState["WorkFlow"] as WorkFlow) ?? new WorkFlow();
//workFlow is null
}
So now inside this function workFlow is null. I want to ask,why is it null when i have set viewstate in page.
Scherand is very correct here. I'd like to add to what he has brought to the table.
Every control that derives from System.Web.UI.Control has the ViewState property. Under-the-hood the property is a StateBag collection. Every instance of a Control has its own StateBag for ViewState, so as Scherand mentioned, ViewState is unique to the control. When the page gets rendered, the entire Control tree of the Page is iterated, all ViewState collections are merged into a tree-like structure and that final structure is serialized to a string and rendered to the page.
Because the ViewState property is marked as protected, you can't get to the Page's ViewState from your User Control without the use of reflection.
But, in all honesty, you should abandon the use of ViewState as a data storage medium. Here are some reasons why:
ViewState gets rendered and output to the client browser. Maintaining data objects in the collection bloats your Page's output.
Unless you have encryption enabled on your ViewState, the encoded string that is rendered to the client browser can be decoded manually and simply anyone can access the content of your data objects. This is a rather significant security vulnerability.
It really sounds like all you want to do is share data between your Page and User Controls. The best way to share data between controls is to make use of the "Items" collection (which is a property of the HttpContext class). The collection is a Hashtable and can be accessed from your Page and User Controls like so:
Context.Items["Workflow"] = workflowInstance;
The best part of using this technique is that it doesn't incur any additional overhead or bloat the Page output. The Items collection exists in the context of a single HTTP request. This means that when your request is done and your Page's output has been rendered to the client browser, the Items collection is cleared from server memory. It's the ideal medium for temporary data storage within ASP.NET.
Now, if you want your data objects to remain accessible for more than just the current request, you'd be better off storing the objects in Session.
I still do not grok everything here (see my comments above). But I am pretty sure you are misunderstanding ViewState.
ViewState is per control, not per request or session or whatever.
In your example, consider some other control (e.g. a standard ASP.NET control) that for some reason decided to put something with a "name" of WorkFlow into viewstate. If what you are trying to do would work, this object would overwrite yours (or the other way around, yours would be overwritten by the other one).
Or am I missing something?
Maybe reading TRULY Understanding ViewState could help you understand what viewstate is/how it works (yes, I really like this article, this is why I keep posting that link).
On postback did you create the control? If the code behind hasn't created the ctrl then it won't know about it.
only applicable if this is a generated control. You may need to post code and more info to get a propper answer.
Viewstate is a monster which is why a lot of us are going to MVC.
the page viewstate is a different statebag from the viewstate that the usercontrol can access. each control has their own private viewstate. So you cannot directly access the page viewstate from a usercontrol code-behind.
you could expose viewstate values with properties or methods and then call those properties/methods
I have a question why we can only add dynamic control using LoadControl.
For example:
public partial class wucReportParam : System.Web.UI.UserControl
{
protected void Page_Load(object sender, EventArgs e)
{
wucDate() ctrl = new wucDate();
pnl.Controls.Add(ctrl);
}
}
When in the page_load method of wucDate, the child control of wucDate is null but when i use the following method:
public partial class wucReportParam : System.Web.UI.UserControl
{
public Report Report;
protected void Page_Load(object sender, EventArgs e)
{
ctrl = (wucDate)LoadControl(#"Reports\wucDate.ascx");
pnl.Controls.Add(ctrl);
}
}
In the page_load method of wucDate, the child control of wucDate is not null.
Is anyone could explain to me why asp .net don't create any child control of wucDate when i using contructor ??? Thank you
When dynamically loading a user control, it is important to ensure that the standard ASP.NET page event pipeline is initiated and progresses normally. When you use the new operator to create an instance of a user control, that user control is not properly added to ASP.NET's event system. If the events (Init, Load, PreRender, etc.) to not fire, then your control will never function properly. That is why it is necessary to use LoadControl, as that will make sure that the instance of your user control is created properly and attached to ASP.NET.
Apparently, using LoadControl with typeof (or GetType) has the same problem as using 'new' where the child controls are not initialized. Using LoadControl with a string to the ASCX file works.
Does not initialize child controls.
LoadControl(typeof(MyReport), null);
Works!
LoadControl("Report.ascx");
The initialization of the controls inside a User Control is driven by the ASCX file. Using only "new SomeControl" will not cause this initialization to run, and even if it did, all the design (markup) in the ascx file would be lost.
Remember that the class "wucDate" is only the base class which the full user control inherits from. It's not the same class as you'll get when using LoadControl("wucDate.ascx").
And to be honest, LoadControl has not much, if anything, to do with the page life cycle. That part is handled when you add the control to the container's Controls collection.
As I recall, it pertains to how ASP.NET constructs page components at run time. In ASP.NET although your pages have a class which is defined in your code-behind file, their types don't truly exist until run time. Like a page, although you have a control defined the wucDate type isn't created until it is included at run time. For this reason, the control must be loaded with LoadControl in order to both initialize the type and properly run in through the page life cycle.
This is to the best of my memory so if I'm incorrect here please let me know.
In an ASP.NET page I have a user control and I want to perform some action within it using javascript. When that action is complete I want to raise an event (again in javascript) to be picked up by the containing ASP.NET page (again in javascript).
The reason I want to do this is because I have more than one user control on the page and I need the action performed in one user control to instantiate an action in another user control without doing a postback.
Does anyone know how to do this?
Many thanks.
Hi and thanks for the response.
What I'm trying to do is create some form of encapsulation. So if the javascript code does something in one user control that user control shouldn't know of the impact else where. It would raise an event in javascript which can be picked up by asp.net page rendered javascript which can in turn call a javascript method in another user control if it needs to.
The idea here is also to eliminate any need for a postback.
Hope this expains it better.
I think the simple way to implement what you are describing, is to forget about JavaScript events, and just supply a "callback" function to the user-controls.
The way i would implement it, would be to expose a public property on the user control, which takes the name of this JavaScript "callback-function". The user-control is then responsible for calling this function after it has finished its client-side job.
So the page that uses the user-controls will have to implement this JavaScript "callback-function", and then supply the name in properties to the user controls.
Makes sense?
You can simply run the javascript you need from the rendered HTML of your user control.
Click Me
By the sounds of things you want to create some form of controller in JavaScript. When the page loads each of your controls register with the controller. Then an action in one of your controls runs a function on the controller, which does something with the controls registered with it.
Your JavaScript could be as simple as:
var oControls = new Array();
doSomething = function() {
for(var i=0;i<oControls.length;i++) {
var oControl = document.getElementById(oControls[i]);
oControl......
}
}
So you need to register your control by using ScriptManager in your user controls render method.
ScriptManager.RegisterStartupScript(Me, Me.GetType(), "Startup", String.Format("oControls.push('{0}');", ClientID), True);
Even when on the page, the EnableViewState property is disabled, I am still seeing some viewstate existing on the page:
"<input type="hidden" name="__VIEWSTATE" id="__VIEWSTATE" value="VkBAB3n5LZYtY+nTzk1vEu1P/6QLf4qzFIKzpFRJe3DMf8UseUA/1RsO409HJX4QhkROSP0umoJvatjK/q+jXA==" />"
My question is why?
It's the control state.
If you really want to get rid of viewstate and controlstate you can use this code in the code-behind for the page, or in any class that the code-behind derives from
class MyPage : Page {
private class DummyPageStatePersister : PageStatePersister {
public DummyPageStatePersister(Page p) : base(p) {}
public override void Load() {}
public override void Save() {}
}
private DummyPageStatePersister _PageStatePersister;
protected override PageStatePersister PageStatePersister {
get {
if (_PageStatePersister == null)
_PageStatePersister = new DummyPageStatePersister(this);
return _PageStatePersister;
}
}
// other stuff comes here
}
Be very careful when doing this, though, since you're violating the contract with the controls. MSDN explicitly states that control state is always available. In practice, however, it has worked for me.
Edit:
Since I was downvoted, I like to point out again: Don't do this unless you know exactly what you are doing. In my case, almost the entire application was written in client-side javascript, and on those few occations where postbacks occurred, I always used the Request.Form collection to retrieve the values. Do not use server-side controls for anything but simple rendering if you do this.
This could be controls that are using ControlState. Any control that has control state will ignore your ViewState settings.
This article is a little old but to my understanding most of the points are still valid:
You must have a server-side form tag () in your ASPX page if you want to use ViewState. A form field is required so the hidden field that contains the ViewState information can post back to the server. And, it must be a server-side form so the ASP.NET page framework can add the hidden field when the page is executed on the server.
The page itself saves 20 or so bytes of information into ViewState, which it uses to distribute PostBack data and ViewState values to the correct controls upon postback. So, even if ViewState is disabled for the page or application, you may see a few remaining bytes in ViewState.
In cases where the page does not post back, you can eliminate ViewState from a page by omitting the server side tag.
http://msdn.microsoft.com/en-us/library/ms972427.aspx
This is an absolutely fantastic article on ViewState if you develop in ASP.NET read it!
ASP.NET ViewState Helper is also a nice tool for seeing what's going on in your ViewState
Controlstate can be the causes. Control state can not be disabled. In ASP.NET 2.0 there is a distinction between data necessary to make a control work (controlstate), and other data (viewstate)
And yes some of the controls don't work without controlstate.
If you want to know which one is causing it or what the viewstate contains check out a viewstate viewer
The Controls which implements IPostBackEventHandler like Textbox, Checkbox, etc. will retain the state even after disabling the viewstate. The reason is during the Load Postback Data stage, these controls will get state information from Posted back form.
But controls like label which do not implement IPostBackEventHandler will not get any state information from posted back data and hence depend entirely on viewstate to maintain the state.