Can a GET request cause IsPostBAck to be true ?
I never tried it but I read that it (somewhere) that it can be done If I add _ViewState , _EventValidation and form params.
It it true ? Can this cause a PostBack ?
Thanks.
edit
I found it here
here
edit 2 after testing - it does WORKING
I didnt't find even one topic about this in the web.
here it is :
http://imageshack.us/f/688/croppercapture1q.gif/
I make a new answer after the update of the question. Actually I make a working example, and I confirm the question, that is can be done !
http://www.planethost.gr/SOPostBackTest.rar
What I do:
I make an aspx page, render it, then get and make an html with the render page, and just change the method from post to get
<form name="form1" method="get" action="PostBackTest.aspx" id="form1">
then I open the html page, and make a get to the aspx page ! and the aspx page is actually see it as IsPostBack.
The results is surprise me. The Flag IsPostBack is set to TRUE, you can see and test it by your self. I do not know how to consider this - BUG, or feature that asp.net work so good that what ever you send them on the form is make it work.
And yes the Request.HttpMethod can show more accurate if is GET or POST command.
Related
I've done some googling on this and i know a question similar to this has been asked several times, but so far I'm not having any luck.
I've got the home page on our site also set up to be the 404/410 error page. When I do a server.transfer to this page the search form on the page no longer works. Response.redirect to this page and it works fine.
So in my code the page doing the server transfer has
Server.Transfer("/default.aspx?status=410", false);
When i then use the search form on default.aspx after getting there from the transfer, i get the error in the title.
I also see that the action value on the form has a value, whereas normally it should be blank. I saw another post suggesting setting this value manually in my content page, but I would have to hardcode the ID for the form and I'm not sure if that would cause issues on other pages since this form is used by all the pages on the site since this master page is the main master page for the whole site. Plus even when i did hard code the ID and then used Page.Master.Findcontrol to get the form and set Action = "" it still had a value set for action instead of an empty string.
I had thought as long as I didn't use Server.Transfer("", true) I shouldn't get this error. And i do have a machineKey entry in my web.config
Anyone have any suggestions on how to resolve this?
Thanks
Server.Transfer()
and Response.Redirect()
both are performing same functionality like help to navigate user from one page to another, but internal process happening inside system little bit different. To get more idea about that please visit
http://www.dotnet-tricks.com/Tutorial/csharp/c4SE281212-Difference-between-Response.Redirect-and-Server.Transfer.html
I think i found a solution, although I'd appreciate some feedback to explain something.
On the page that's being transferred to (default.aspx) I tried using Form.Action = "" and when i loaded the page that resulted in the action being something like action="/../../../default.aspx"
Just now i tried it again but I used Form.Action = "/", which did set the action to "/" and that seems to work.
So i guess my question is why did trying to set the action to "" result in that relative url?
And is this the correct way to handle this problem?
Thanks
I am using using Response.Redirect to transfer control to another page. but this disables back navigation in the browser. What is alternative way to achieve this ?
Response.Redirect does not disable the back button by any means. Check it using web-console or put debug point on your page and check again. I think in your case the browser back button is working but your page may be forcing it to redirect again to the second page
You can do a client-side redirect.
Here is code for 5 different ways to do this with JavaScript
I recommend the first one which is to set the window.location.href property in JS.
You should use Server.Transfer() instead.
You must have added a javascript function somewhere in your project ( like MasterPage or parent page ) which is disabling back button and which is bad from user point of view , otherwise it isn't possible for browser's back button to get disabled on its own just because you have used response.redirect in your code -behind .
I have a situation that I am stuck with, and hoping someone can help. I am building a .NET/C# web application in which I have a tabbed panel layout, and when the user clicks on each of the tabs the display panel is updated using javascript to hide and show some divs. None of these clicks cause postback, it is all client-side, so I can't use viewstate or session.
What I want to do is somehow remember which panel was last visible when the page is refreshed, yet without posting back to the server I am unsure how to do this. I have tried a hidden field but obviously its value is reset every time because the form is never submitted. I do know that I can achieve this using cookies but its a little annoying to implement for such a (seemingly) trivial operation ... but maybe this is the only way?
Does anyone have any more elegant solution to this problem?
Using a function like this to show and hide tabs):
function makeCurrent(tab) {
if (tab.title == 'Manage orders') {
document.getElementById('panelOrders').style.display = "block";
// Hide others
document.getElementById('panelAccounts').style.display = "none";
document.getElementById('panelProducts').style.display = "none";
document.getElementById('panelSettings').style.display = "none";
// Remember last viewed panel
document.getElementById('hdnCurrentlyViewing').value = "orders";
}
The panels are just divs with style.display controlling their visibility. Not sure if its useful to post HTML code because its fairly self explanatory ...?
You can make this happen without a postback is to make an AJAX call from Javascript where you tell your server what the current panel is as you switch it.
I prefer using a framework like JQuery or Prototype to help make these AJAX calls myself.
I think Hidden field will be the best option. have you tried ASP:HiddenField? It can be accessed across postbacks.
But if you still have some reservations with postbacks and hiddenfield you can also use cookies from JS http://techpatterns.com/downloads/javascript_cookies.php this is helper lib for cookies manipulation within JS.
Regards.
I am interested to know what specifically Page.IsPostBack means. I am fully aware of it's day to day use in a standard ASP.NET page, that it indicates that the user is
submitting data back to the server side. See Page:IsPostBack Property
But given this HTML
<html>
<body>
<form method="post" action="default.aspx">
<input type="submit" value="submit" />
</form>
</body>
</html>
When clicking on the Submit button, the pages Page_Load method is invoked, but the Page.IsPostBack is returning false. I don't want to add runat=server.
How do I tell the difference between the pages first load, and a Request caused by the client hitting submit?
update
I've added in <input type="text" value="aa" name="ctrl" id="ctrl" /> so the Request.Form has an element, and Request.HTTPMethod is POST, but IsPostBack is still false?
Check the Request.Form collection to see if it is non-empty. Only a POST will have data in the Request.Form collection. Of course, if there is no form data then the request is indistinguishable from a GET.
As to the question in your title, IsPostBack is set to true when the request is a POST from a server-side form control. Making your form client-side only, defeats this.
One way to do this is to extend the ASP.NET Page class, "override" the IsPostBack property and let all your pages derive from the extended page.
public class MyPage : Page
{
public new bool IsPostBack
{
get
{
return
Request.Form.Keys.Count > 0 &&
Request.RequestType.Equals("POST", StringComparison.OrdinalIgnoreCase);
}
}
}
In the example that you include in your question, there is no viewstate involved; there is no way for the server to link this request to a previous request of the page and treat them as a unit. The request resulting in clicking the button will look like any other random request coming in to the server.
Generally a you could view a PostBack as a combination of:
HTTP request method equals "POST"
HTTP header HTTP_REFERER equals the current URL
That's not 100% foolproof tho, it does not take into account any state of any kind (which you probably want even if you don't know it) but it is a post, back to the current page.
You could check the headers to see if your input controls are returning a value (using Request.Forms as tvanfosson points out). However, the really big question is why you would not want to add runat=server. The entire page processing edifice implemented by ASP.NET (except MVC) depends on processing the page output through the server to set up the appropriate client-side code for callbacks, etc.
The __doPostBack is not working in firefox 3 (have not checked 2). Everything is working great in IE 6&7 and it even works in Chrome??
It's a simple asp:LinkButton with an OnClick event
<asp:LinkButton ID="DeleteAllPicturesLinkButton" Enabled="False" OnClientClick="javascript:return confirm('Are you sure you want to delete all pictures? \n This action cannot be undone.');" OnClick="DeletePictureLinkButton_Click" CommandName="DeleteAll" CssClass="button" runat="server">
The javascript confirm is firing so I know the javascript is working, it's specirically the __doPostBack event. There is a lot more going on on the page, just didn't know if it's work it to post the entire page.
I enable the control on the page load event.
Any ideas?
I hope this is the correct way to do this, but I found the answer. I figured I'd put it up here rather then in a stackoverflow "answer"
Seems it had something to do with nesting ajax toolkit UpdatePanel. When I removed the top level panel it was fixed.
Hope this helps if anyone else has the same problem. I still don't know what specifically was causing the problem, but that was the solution for me.
Check your User Agent string. This same thing happened to me one time and I realized it was because I was testing out some pages as "googlebot". The JavaScript that is generated depends on knowing what the user agent is.
From http://support.mozilla.com/tiki-view_forum_thread.php?locale=tr&comments_parentId=160492&forumId=1:
To reset your user agent string type about:config into the location bar and press enter. This brings up a list of preferences. Enter general.useragent into the filter box, this should show a few preferences (probably 4 of them). If any have the status user set, right-click on the preference and choose Reset
I had this same problem (__doPostBack not working) in Firefox- caused a solid hour of wasted time. The problem turned out to be the HTML. If you use HTML like this:
<input type="button" id="yourButton" onclick="doSomethingThenPostBack();" value="Post" />
Where "doSomethingThenPostBack" is just a JavaScript method that calls __doPostBack, the form will not post in Firefox. It will PostBack in IE and Chrome. To solve the problem, make sure your HTML is:
<input type="submit" id="yourButton" ...
The key is the type attribute. It must be "submit" in Firefox for __doPostBack to work. Other browsers don't seem to care. Hope this helps anyone else who hits this problem.
this might seem elemental, but did you verify that your firefox settings aren't set to interfere with the postback? Sometimes I encounter similar problems due to a odd browser configuration I had from a debugging session.
Is it because you are doing return confirm? seems like the return statement should prevent the rest of the code from firing. i would think an if statement would work
if (!confirm(...)) { return false; } _doPostBack(...);
Can you post all the js code in the OnClick of the link?
EDIT: aha, forgot that link button emits code like this
<a href="javascript:__doPostBack()" onclick="return confirm()" />
Are you handling the PageLoad event? If so, try the following
if (!isPostBack)
{
//do something
}
else if (Request.Form["__EVENTTARGET"].ToLower().IndexOf("myevent") >= 0)
{
//call appropriate function.
}
Check if you are getting a call this way, if so then maybe the event is not wired and nedes to be explicitly called.
what do you expect from "Enabled = 'false'" ?
I have had problems with firebug on some web forms, something to do with the network analyser can screw with postbacks.
With or without the OnClientClick event it still doesn't work.
The _doPostBack event is the auto generated javascript that .NET produces.
function __doPostBack(eventTarget, eventArgument) {
if (!theForm.onsubmit || (theForm.onsubmit() != false)) {
theForm.__EVENTTARGET.value = eventTarget;
theForm.__EVENTARGUMENT.value = eventArgument;
theForm.submit();
}
}
*The &95; are underscores, seems to be a problem with the stackoverflow code block format.
Now that i think about it, as noted in my last edit, you want to drop the javascript: in the on client click property. It's not needed, because the onclick event is javascript as it is. try that, see if that works.
Seems it had something to do with nesting ajax toolkit UpdatePanel. When I removed the top level panel it was fixed.
Hope this helps if anyone else has the same problem.
I had this exact same issue in a web app I was working on, and I tried solving it for hours.
Eventually, I did a NEW webform, dropped a linkbutton in it, and it worked perfectly!
I then noticed the following issue:
...
I switch the order to the following, and it immediately was fixed:
...
IE had no issue either way (that I noticed anyway).
I had a similar issue. It turned out that Akamai was modifying the user-agent string because an setting was being applied that was not needed.
This meant that some .NET controls did not render __doPostBack code properly. This issue has been blogged here.
#Terrapin: you got this exactly right (for me, anyways).
I was running User Agent Switcher and had inadvertently left the Googlebot 2.1 agent selected.
In Reporting Services 2008 it was causing the iframes that reports are actually rendered in to be about 300x200 px, and in Reporting Services 2008 R2 is was throwing "__doPostBack undefined" errors in the Error Console.
Switching back to the Default User Agent fixed all my issues.
I had the same problem with Firefox. Instead of using __doPostBack() could you use the jQuery .trigger() method to trigger a click action on an element that has your postback event registered as the click action?
For example, if you had this element in your aspx page:
<asp:Button runat="server" ID="btnMyPostback" OnClick="btnMyPostback_Click" CssClass="hide" ToolTip="Click here to submit this transaction." />
And your postback event in your controller:
protected void btnMyPostback_Click(object sender, EventArgs e)
{
//do my postback stuff
}
You could do the postback by calling:
$("#btnMyPostback").trigger("click");
This will cause the Page_Load event to fire if you need to do something on Page_Load.