We Keep Coding

Is it possible to ignore/change the url from PostBackUrl in asp.Button from code behind?

I'm working with ASP.NET webforms and I'm wondering if it is possible to change/ignore the PostBackUrl so it won't change pages.
My button:
<asp:Button ID="continuebtn" OnClick="Continuebtn_Click" runat="server" PostBackUrl="~/client/profile.aspx" CssClass="btn btn-success btn-sm" Text="Continue"/>
And the OnClick function is:
protected void Continuebtn_Click(object sender, EventArgs e)
{
//some code
if(condition == false)
//change the url from PostBackUrl so it won't change pages
else
//keep the current Url
}
I've tried :
continuebtn.PostBackUrl = "";
continuebtn.Attributes["PostBackUrl"] = "return false";
continuebtn.Attributes.Remove("OnClick");
continuebtn.Attributes.Add("OnClick","return false");
continuebtn.OnClientClick = "return false;";
add return; to if
I tried to remove the PostBackUrl from the button and add it from the code behind with continuebtn.PostBackUrl = "~/client/profile.aspx" but it didn't work either.

There are two big reasons to use post-back URL in place of say using a code behind click event and say then response.Redirect("some web page").
First up, post-back url passes the previous page!!!!!
So, if you have say a text box and a button like this: (or evne a grid view)
Now you can use code behind to jump to the next page, or you can use/set/have post-back url set.
If you use post-back URL. Then you don't need to write a code behind stub, and you ALSO get use of previous page in the next page on-load event (you ONLY can pick up previous page in load - first time).
eg:
protected void Page_Load(object sender, System.EventArgs e)
{
if (IsPostBack == false)
{
TextBox tbox;
tbox = Page.PreviousPage.FindControl("TextBox1");
Debug.Print("Text box = " + tbox.Text);
TextBox1.Text = s;
}
}
}
so post-back url = a great way to pass/get at/use the previous page values with find control. Now if you not needing to do this, then you probably should not use post-back URL, since you are bulking up the payload for the next page (it will contain the current page, and you have as noted use of "previous page". However, it is a fantastic way to avoid parameters and/or cluttering up session() just to pass a bunch of values. Just use post-back URL and then like "magic" then previous page can be used. if you don't use post-back URL then previous page is null and not valid.
And if you place two buttons on the page? Can you set postback url? Sure you can set that control, text box or do anything you like - but do keep in mind that the code behind is running AFTER a post-back, and it will of course be too late to change a button that CAUSED the post back.
So, you can certainly do this in button2 click even to change button1:
protected void Button3_Click(object sender, EventArgs e)
{
Button1.PostBackUrl = "";
}
So in above, button3 click event and code behind wiped out the post-back URL of button one. Or we can of course set the url to anything we want.
Now, the code behind is done, page is rendered and THEN sent back down to the browser with the above change. If user hits button1, then no postback url exists - we blew it out with the above code.
However, in the SAME button event? no, it is too late to change or modify the post-back.
In that case, and if you need "conditional" jump? Then you need to delete and remove the post-back url, and simply put the logic you need to determine the ya, or nay jump based on the code behind for that click event.
HOWEVER - and a BIG WHOPPER however? If you JUST use a response.Redirect("some web page") in that code behind, then you DROPPIGN THE MAIN reason as to why the developer used post-back URL in the first place. That main, big, huge, large reason is that post-back URL gives the next page in line FULL USE of the previous page values with "previous page". If you do NOT use post-back URL, then you can't use previous page to pass all those values and inspect and get and grab control values from the previous page.
So what if you really did need the "abilities" that post-back URL provides (that ability of course is "previous" page in the next page load!
In that case, then you have to use Server.Transfer() in that code stub to get use of previous page in the next page that loads.
So, regardless:
You can't change post-back URL in the same button code event - it is too late.
If you are going to then put the logic in the code event? Then be VERY VERY aware that if you use a response.Redirect("some web page"), then you may VERY well be breaking the functionally of why in the first place the developer used post-back url (to have use of "previous page".
Your suggested idea to modify client side the post-back url in one button click, and then do a js "click" of that button you just changed the post-back url should also work (good idea!!!).
But, I would thing that just using a code behind stub in the click event, and then the code can choose to navagate or jump to the next page based on that code? Right?
However, if you do that, then you will break the "features" of post-back URL in pasing page prevous.
In that case? Then you need to use a server.Transfer("to next web page") in place of response.Redirect("to next web page), since a server.Transfer will give you use of "page previous" in the next page load event JUST LIKE post-back URL does!
Of course with a server.Transfer, you will note that the web page URL does not change or update - and this is a fall out of having to do this. (and may, or may not matter to you).

WebBrowser and javascript

I am working with a website that has javascript that does some changes on the page load. However, when I load the page and handle the DocumentCompleted event, this change isn't there. If I then continue paste the DocumentCompleted event, I can see the change happen. However I need this change to happen during DocumentCompleted so I can check some things.
Is there an other event I can subscribe to, or a way to cause the webBrowser to do all the javscript on page?
Edit: This is what I am talking about.
I loaded a sample page just to show you, and clicked the submit button with all fields empty to generate an the error.
Here is the result:
http://s8.postimage.org/zfv6stcar/sfsdfsdfds.jpg
Now if I take the HTML at that precise moment from that WebBrowser control, and render it somewhere else, those errors go away. The same thing happens when the server sends back those errors. If I handle the DocumentCompleted event and take the html, it isnt there. But after the event, it shows up in the control.
Hope you understand, it's hard to explain.

The problem seems to be that the DocumentCompleted event is being fired before the javascript. You should do some reading on how client side/server side things function.
One option is to make a separate method for the DocumentCompleted event and call it form the javascript after it has been completed. This would get the sequencing of these events working properly, but is not very ideal.
Alternatively, you could call the javascript code at the beginning of your DocumentCompleted event. The link below gives a pretty good explanation of how to go about that.
http://forums.asp.net/t/1117189.aspx/1
Personally, I would avoid using javascript and do the validation on the client side .NET, but I don't know enough about the website to really say.
EDIT:
This should be the script you are looking for. Alternatively here is a thread related to your issue. Sorry I don't have the exact code as I don't have a project to test this on.
http://msdn.microsoft.com/en-us/library/system.web.ui.clientscriptmanager.registerstartupscript.aspx
Calling JavaScript Function From CodeBehind
RE-EDIT:
What is happening on the link you provided in the comments, is that each textbox is calling some javascript as well as the submit button. The best way to examine this is using the "Inspect Element" in the right-click menu on Google Chrome. For example, doing this on the textbox would show that it is registered with a few events:
onfocus="$('f_tip_Username').style.display = 'inline'"
onblur="$('f_tip_Username').style.display = 'none'"
onchange="$('f_err_Username').style.display = 'none'"
The first the element with the ID 'f_tip_Username', sets the display style of that element to inline (visible).
The submit button calls the following:
onclick="return o_edit_profile_form.validate()"
Doing a find on "o_edit_profile_form" in the source code, you can find the exact javascript location that is being called. Enjoy!
FINAL EDIT (hopefully?):
Follow these steps: go to your site, right click and go view source. Do a find for "f_tip_Username". This is the ID of one of the div tags being used. The third entry of it, should be a "div tag" that is used under the first textbox to warn of "min 3 characters".
You'll notice above that in the code is a input type "text" with the Name "Username". Notice the three events it has registered in it:
onfocus="$('f_tip_Username').style.display = 'inline'"
onblur="$('f_tip_Username').style.display = 'none'"
onchange="$('f_err_Username').style.display = 'none'"
These either hide or make visible, the div tag we found (f_tip_username) and also a separate div tag (f_err_Username) which is the error message div tag. Let me know if you are not able to find these in the source. Follow the steps I provided and you will find it in the "view source" OR in the DocumentText.

create a back button that uses javascript or respose.redirect

Im using asp.net c# (webforms)
I want to add a back button to my page. (you land on this page if you incorrectly fill in a form).
if javascript is enabled i want to go back via javascript, but if it is disabled i'll just do a response.redirect("~/home.aspx")...
how can i implement this? is it 2 buttons? how can i hide the other in the 2 different states if so.
thanks

<asp:Button OnClick="serverMethod" OnClientClick="return(jsMethod);" runat="server" ID="redirectButton" Text="Back" />
on the button, but set the OnClientCLick to:
return(javascriptredirect());
and the OnClick to your button click event handler in your code behind.
if javascript is enabled, it will do the javascript redirect, if not enabled the page will post back and you can do your OnClick code behind method whic can to the response.redirect. You can also return false from your function to prevent the postback from occurring such as the case with setting the OnClientClick="return(confirm('Are you sure?'));"

This link guides you how to do it http://aspadvice.com/blogs/azamsharp/archive/2007/09/30/Check-If-the-JavaScript-is-Enabled-on-the-Client_2700_s-Browser.aspx
Happy coding !!!!!!

Run javascript function after Server-Side validation is complete

Ok, I've got a lightbox with a small form (2 fields) in it, inside an UpdatePanel, and I want to close this lightbox (must be done via javascript) when the 'Save' button is pressed.
However, there is a need to have a server-side CustomValidator on the page, and I only want to close the lightbox if this returns as valid.
Does anyone know a way to trigger javascript (or jQuery) code from a server-side validator?

You can add a little snippet of code using the ScriptManager to execute after the response comes back to the UpdatePanel.
if (Page.IsValid){
ScriptManager.RegisterStartupScript(
customValidator1,
typeof(MyPageClass),
"closeBox",
"myLightBoxVariableOnThePage.close()",
true);
}

When that server side validator runs, it will send a whole new page to the browser. Anything that was shown in the browser before was destroyed, including any state kept in your javascript. If new page bears a strong resemblance to the old page, you should consider this a happy coincidence.
Therefore, the thing to do here is rather than executing a javascript function, have your CustomValidator make the correct changes to the page on success so that it's rendered to the browser correctly in the first place.

user control event handler lost on postback

I have a menu usercontrol called LeftMenu that has a bulletedlist of linkitems. It's on the ascx page as such:
<asp:BulletedList ID="PublisherList" DisplayMode="LinkButton" OnClick="PublisherList_Click" cssClass="Menu" runat="server"></asp:BulletedList>
I databind the list in the page_load under if(!isPostBack)
I'm having an issue on a page that loads the control. When the page first loads, the event handler fires. However, when the page posts back it no longer fires and in IE8, when I'm debugging, I get "Microsoft JScript runtime error: Object expected" in Visual Studio pointing at "__doPostBack('LeftMenu$PublisherList','0')." In FF I don't get the error, but nothing happens. I'm not loading the control dynamically, it's loaded on the aspx page using:
<%# Register TagPrefix="Standards" TagName="LeftMenu" Src="LeftMenu.ascx" %>
<Standards:LeftMenu ID="LeftMenu" runat="server"/>
Any ideas of where I'm losing the event handler?
I just realized this is happening on another user control I have as well. A text box and a button and I'm using the default button to make sure pressing the enter key uses that button. .Net converts that in the html to:
<div id="SearchBarInclude_SearchBar" onkeypress="javascript:return WebForm_FireDefaultButton(event, 'SearchBarInclude_QuickSearchButton')">
so as soon as i enter a key in the box I get a javascript error at the line saying "object expected." It seems like the two issues are related.
Edit Again: I think I need to clarify. It's not that I'm clicking on the menu item and it can't find the selected item on postback. I have this search page with the left navigation on it and then the main content of the page is something that causes a postback. Everything is fine with this postback. Once that page has been posted back, now if I click on the bulleted list in the left navigation I get a javascript error and it fails. The page_init for the LeftMenu control is never called.

It sounds like you might be losing the click because you are not DataBinding the list on PostBack. Therefore, the post back is trying to refer to a control (a specific bulleted list item) that does not exist.
You should try binding the list again on PostBack just to see if that fixes your issue. BUT, what should REALLY happen is that the LeftMenu and the BulletedList should store their information into ViewState so that you can ensure that the data that was shown to the user on their initial page load is the same data that the PostBack is processing and working with.

If you have EnableViewState=true for your UserControl and all controls within it, everything should work fine. With ViewState enabled, ASP will reinflate your controls from ViewState after Init has fired. This means that the postback event arg (which points to an index in your control list) will still find the control in that list position. Otherwise the list is empty on postback.
However, ViewState is the work of the devil and was designed simply to foster the illusion that you are working in a stateful environment. It is okay to use it for small amounts of data but typically not advisable for templated controls like repeaters and lists because you have no idea how much data is going to be created in ViewState.
If you are dealing with static, or relatively static data, store it in the application cache and rebind your lists in Page.Init every time (note that it has to be in Init because post-init is when ASP rebinds from ViewState; if you get in there first, your data will be used instead).
If you are dealing with volatile data, you have a problem because the data you rebind must be exactly the same as the original page request, otherwise the postback events will be firing against the wrong rows. In that case you need to either store your initial data in Session or you simply store the list of rows ids (in a hidden variable or Session) and you recreate the data to bind against from the ids each time.
An even better solution is to not use postback events at all. Try to turn all your events into GETs that have an ID on the query string. You can still create the list using binding the first time through the page (as you are currently doing), and you can even GET the same page with a new ID.
If you need to keep state on the same page but need to respond to the user changing a radio button selection (or something else), think about using Ajax calls to update the screen. You also do that with an ID that you pass to the Ajax call.
In general, the more you move from using stateful ASP, the lighter and more responsive your pages will become. You will also be in a better position to move to stateless MVC if necessary. You will also save lots of time lost to debugging obscure problems because ViewState is not available when you need it to be.
The best analysis of ViewState I've read is in the link below. If you fully understand how it works, you can continue to use it without necessarily incurring the costs.
http://weblogs.asp.net/infinitiesloop/archive/2006/08/03/truly-understanding-viewstate.aspx

It's possible that this might be javascript related, and that a script that is loading earlier in the page is throwing an error and causing the page to not be loaded properly.
Are your usercontrols loading any javascript onto the page? Can you check for javascript errors on the initial load of the page?

I moved the code into an existing project we have and for some strange reason, I stopped getting the javascript errors and instead got:
"Invalid postback or callback argument. Event validation is enabled using <pages enableEventValidation="true"/> in configuration or <%# Page EnableEventValidation="true" %> in a page.
For security purposes, this feature verifies that arguments to postback or callback events originate from the server control that originally rendered them. If the data is valid and expected, use the ClientScriptManager.RegisterForEventValidation method in order to register the postback or callback data for validation."
I haven't quite figured out where I'm supposed to put the register event validation with a user control, but in the mean time I just set enableeventvalidation=false and it seems to work now.

It looks like the doPostBack function is missing since its arguments are literals so they couldn't be the cause. Is that one of your own functions or did you mean to call the ASP __doPostBack function?
Have a look at the Firefox error console or allow script debugging in IE and see exactly what object can't be found. Even better, download Firebug and debug it.

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.