Is there any difference between using This.IsValid vs Page.IsValid?
Page IsValid shows you if whole page is valid
this.IsValid returns information if object and each controls on it is valid.
'this' could be for example user control, so result could be different.
If this.IsValid is false then Page.IsValid is also false, but if this.IsValid is true then you are not sure that Page.IsValid is also true.
It depends on the context. In your webpage's code-behind file, in your webpage's event functions, this is getting your actual webpage instance (which inherits Page), and calls it's .IsValid method.
Page.IsValid() would be the same as this.Page.IsValid(). In this case, Page is getting a reference to the page that the calling control resides in (this), which would be the same instance as what I described above. So, in this sense, there's no difference.
Related
is there any way out to detect the full postback is occurred or partial postback occur when we work with PageMethod. if firebug is install then how could i check the size of response. can anyone help me to detect it because in my case pagemethod is taking bit more time to send back the response to client. i am not very aware the use of firebug. how to check the response size with fire but when partial postback will occur with the help of pagemethod. thanks
If you have partial postbacks then you are probably either using page methods as web-services or something (like the UpdatePannel) that requires a ScriptManager.
If you are using page methods, you can check the page's IsCallback property which returns true if the page request is the result of a callback; otherwise, false.
If you have a ScriptManager on the page you can use its IsInAsyncPostBack which returns true if the current postback is executing in partial-rendering mode; otherwise, false.
What is this keyword how can use it?
If Page.IsPostBack = False Then
IsPostBack
Here is an overview of IsPostBack from MSDN:
http://msdn.microsoft.com/en-us/library/system.web.ui.page.ispostback.aspx
It quotes:
true if the page is being loaded in
response to a client postback;
otherwise, false.
The postback is useful, say for example you have a Literal control on the page, and the code on page load sets the Literal.text += "hello"; If you have a button on that page, and press it, the text of the literal will get longer and longer, hellohellowhello, if you wrap the code in (c# example):
if(!Page.IsPostBack){
Literal.text += "hello";
}
The Literal text now wont expand when the button is pressed.
Other Notes
Instead of:
If(Page.IsPostBack = False)
Do:
If(!Page.IsPostBack)
This is logically the same and is generally accepted to be a better way of writing the statement.
Also you marked the question C#, but the If syntax you used indicates you are writing it in VB.net, not C#.
Gets a value indicating whether the page is being loaded in response to a client postback, or if it is being loaded and accessed for the first time.
Return Values:
true if the page is being loaded in response to a client postback; otherwise, false.
http://msdn.microsoft.com/en-us/library/system.web.ui.page.ispostback.aspx
The IsPostBack tells you whether or not the page has been Posted Back, meaning "server side" button has been clicked.
You can "use" it by reading its value and acting upon it.
It's useful for example when you add controls dynamically to your page, so you don't have to add them when it's a PostBack.
Official documentation already been posted by others, look there for any further or technical details.
I'm fairly new to the .NET framework model of doing things so any help/suggestions would be much appreciated. Basically I want to call a user control from a master page. However, I need to pass an object (a List of objects to be more specific), to the user control. I'm generating the list of objects in the Page_Load of the master page. Here's the line in my master page that calls the user control.
<cu:Eventlisting1 runat="server" id="eventListing1"></cu:Eventlisting1>
This user control has a parameter called CalendarItems that accepts the list of items. However, if I try to set this inside of the Page_Load method, my control executes before the Page_Load and throws an exception saying CalendarItems is null. Is there any way around this?
EDIT:
To try to help clarify. I have a drop down list on this page that determines what the list of CalendarItems is so when I populate the CalendarItems list I need to be able to read the selected value from the drop down list.
You can call a initControl-function(the code that causes the exception now) from setCalendarItems.
I would normally prefer this over abusing the page-lifecycle (use Page.Init) because that could cause other problems(viewstate etc.).
Defining an initControl function in your usercontrol and call it from the controller(Page or Masterpage)after you set the CalendarItems would probably the best, because you keep as much control as possible(better than call initControl from the property).
Try populating your list in the Init method of the page, your control will be loaded and it happens before the page load event.
Ok, I thought I understood these topics well, but I guess not, so hopefully someone here can clear this up.
Page.IsAsync seems to be broken. It always returns false.
But ScriptManager.IsInAsyncPostBack seems to work, sort of.
It returns true during the round trip for controls inside UpdatePanels. This is good; I can tell if it's a partial postback or a regular one.
ScriptManager.IsInAsyncPostBack returns false however for async Page Methods. Why is this? It's not a regular postback, I'm just calling a public static method on the page.
It causes a problem because I also realized that if you have a control with AutoPostBack = false, it won't trigger a postback on it's own, but if it has an event handler on the page, that event handler code WILL run on the next postback, regardless of how the postback occurred, IF the value has changed.
i.e. if I tweak a dropdown and then hit a button, that dropdown's handler code will fire. This is ok, except that it will also happen during Page Method calls, and I have no way to know the difference.
Any thoughts?
As Tjaart points out, Page.IsAsync has nothing to do with AJAX! See MSDN for a bit more info about IsAsync and see http://msdn.microsoft.com/en-us/magazine/cc163725.aspx for a fuller description of async pages].
Page methods are web services by a different name. The ScriptManager will emit the necessary JS boiler plate to make creating an XHR that invokes the web service very easy but that's all ScriptManager has to do with them really.
As the MSDN page states, ScriptManager.IsInAsyncPostBack will only be true if the request is in "partial rendering mode" so ScriptManager.IsInAsyncPostBack will be false when you are executing a page method because that request has not been spawned as a result of a partial postback (i.e. an UpdatePanel refreshing its contents).
Now it sounds like you are getting server side event handlers being executed as an apparent result of calling a page method from JS. AFAIAA, invoking a page method using javascript should not cause the page to go through its normal page lifecycle - so Page load, init etc. and these events should not be executing. So that is strange.
Suggestion: -
See Anz's comments and Dave's replies here encosia.
Could it be that you are having similar problems to Anz? i.e. The page method is invoked and but then your page is posting back immediatly after?
This is so because ASP.NET Ajax and ASP.NET Callbacks are two different things and are implemented differently. Unfortunately you have to use both Page.IsAsync and ScriptManager.IsInAsyncPostBack.
Page.IsASync probably returns whether the page was set as Async in the page directive
<%# Page Language="vb" Async="true" ...
The autopostback flag is so that you don't get a postback after every single control action, so the user can fill in an entire form and then only create the postback and trigger all the related code.
It's not really weirdness, they designed it this way so that the server side code will always be synchronized with the client side. So if you make a drop down list selection on the page and a postback occurs then that drop down list change executes it's own code along with the control that triggered the postback. You may want to read up more on the ASP .Net page lifecycle. it made things much more clear for me.
I have a custom class (ServerSideValidator.vb) that validates user input on server side (it doesn't use any of the .NET built in validators, therefore Page.Validate() is not an option for me). I am calling the Validate() method on page.IsPostback event and the class performs without any problem
My issue is, when validation fails (returns false), I want to stop the postback event handler from firing, but load the page along with all the controls and user-input values in them. If I do, Response.End(), the page comes up blank. I can programmatically instruct the page to go to the previous page (original form before postback), but it loses all user-inputs.
I thought of creating a global boolean variable in the page code behind file and check the value before performing any postback method, but this approach takes away from my plan to provide all functionalities inside the class itself. The page object is being referenced to ServerSideValidator.
Seems like all the postback related properties/variables I come across inside Page class are 'Readonly' and I can't assign value(s) to control/prevent postback event from firing.
Any idiea on how I can accomplish this? Please let me know if you need further details
It's probably easier to post back to the same page every time and do your validation there, specifically on the page load event. If the validation fails, you're already on the correct page and don't have to go to a previous page. If the validation succeeds, then you can redirect to another page if you wish, in which case you probably don't need any data.
Edit: This isn't exactly what you asked for, but I have a feeling it will do what you want while fitting into the existing ASP.NET validation design. See http://www.dotnetcurry.com/ShowArticle.aspx?ID=197 and https://web.archive.org/web/20211020145934/https://www.4guysfromrolla.com/articles/073102-1.aspx
Basically, you create a custom class just like you have now, but inherit from BaseValidator. To follow your design, you can create an enum called ValidationType which has Alphabetic, Alphanumeric, etc. In your custom class, create a property called ValidationType that uses the ValidationType enum. Of course you have to add all the validation logic. Then in your aspx page, you can add your custom validator to the page and set ValidationType="Alphabetic", etc. with full IntelliSense support.
Since you use BaseValidator, all the regular validation techniques will work including Page.Validate(), Page.IsValid, etc. You can even create client-side validation JavaScript if you wish.
Having said this, someone has probably already done most of this for you.