I've just implemented a small UpdatePanel with a button outside the panel that modifies the controls within it. Per instructions here and here I have set up a trigger on Page_Load that looks like this...
UpdatePanel1.Triggers.Add(item: new AsyncPostBackTrigger
{
ControlID = Button1.UniqueID
});
...in order to allow the button click event to update the panel asynchronously (it was refreshing the whole page before). However, now it works asynch the first time, but every other click after that triggers a whole page refresh. I'm pretty confused by that one. Can anyone spot what's wrong? (Edit: To clarify, the following represents the refresh results of a series of clicks starting after page load: Asynch (good), Whole Page (bad), Asynch, Whole Page, Asynch, Whole Page, etc...)
FYI the form is ASP.NET 4.0 and resides in a SharePoint 2013 visual web part, if that matters.
try scriptmanager EnablePartialRendering property like this
<asp:ScriptManager ID="ScriptManager1" runat="server" EnableViewState="False" EnablePartialRendering="true"> </asp:ScriptManager>
Related
I need a DropDownlist which can cause SelectedIndexChanged event but do not do post back(do not need page_load event when ddl index changed).
After looking into solutions in Stack here is my code:
<asp:UpdatePanel runat="server">
<ContentTemplate>
<asp:DropDownList ID="a" runat="server" OnSelectedIndexChanged="a_SelectedIndexChanged">
<asp:ListItem Text="a"></asp:ListItem>
<asp:ListItem Text="b"></asp:ListItem>
</asp:DropDownList>
</ContentTemplate>
<Triggers>
<asp:AsyncPostBackTrigger ControlID="a" EventName="SelectedIndexChanged" />
</Triggers>
</asp:UpdatePanel>
and C# code:
public partial class TestApp : System.Web.UI.Page
{
protected void Page_Load(object sender, EventArgs e)
{
txtDate.Text = DateTime.Now.ToString("yyyy-MM-dd");
}
protected void a_SelectedIndexChanged(object sender, EventArgs e)
{
int a = 1;
}
}
But the break point in put in a_SelectedIndexChanged never gets fired. What could be the issue here?
As you see the above is an accpeted answer on stack, then how its not workining:
How DropDownList's SelectedIndexChanged() works without PostBack?
Edit: While the below answer correctly explains that page_load should fire all the times. I still want to know why SelectedIndexChanged never gets fired. So what EventName="SelectedIndexChanged" in the Trigger does?
While a update panel (UP for this post) will "ajax" up, and ONLY post-back that part of the page. (and code behind for that UP can only update controls in that UP?).
The page load even will ALWAYS fire each time.
In fact, page load fires for any button click, post-back, changed event or anything at all.
Thus, as a STANDARD design pattern?
If your page load event loads up a drop down list, listbox, gridview etc.?
Then you ONLY want that code to run on the "real" first page load.
As a result, the last 200+ web pages I have built?
They have this:
protected void Page_Load(object sender, EventArgs e)
{
if (!IsPostBack)
LoadData();
}
void LoadData()
{
Repeater1.DataSource = General.MyRst("SELECT * from tblHotelsA");
Repeater1.DataBind();
}
So, in above example, I am loading up a "repeater" with some data.
However, REGARDLESS if you using a UP or not?
Your page load code, first time MUST quite much do the above.
If you don't do the above, then simple code that say loads up a dropdown list (combo box) will fire each and every time.
If then if you select a combo box value, then say click a button on the page?
the page load fires first, AND THEN your button code. But, if page load re-loads the combo box, then you lose your selection.
So, update panel or not?
Your page load event fires each and every time - including when you use that UP.
So, even without a UP, it stands to reason you can't really even build a working web page if you page load event EVERY time loads up data and controls, since then any changes to such controls will be "blowen" out, and over written each time.
So, while the UP results in what "appears" to not be a post-back?
it is in fact what we call a partial post-back. And the standard page life cycle does occur, but ONLY the bits and parts in the UP are posted back to the server, and in that case, ,then the code behind of course can only change/modify the controls inside of that UP (quite much the whole idea).
So, while the UP will "eliminate" the browser spinner, and while it KEEP your current scroll position on the page?
Make no mistake here - that partial post-back is in fact a page post-back, but just a smaller one, and one that looks to the user that no post-back occurred.
so, it is fine and dandy to have auto-post back for that dropdown list. (and you do NOT even require a trigger, and I suggest you remove the trigger, and put back in the auto post-back.
So, the UP does not "eliminate" the post-back, but hides this from the end user, and for the most part it can be rather nice, quick, and of course will not refresh the whole page. But, page load still fires each and every time.
So, for your code to work correctly, and only fire on the VERY first time, and what amounts to the "real" first page load?
Then your code has to be this:
protected void Page_Load(object sender, EventArgs e)
{
if (!IsPostBack)
{
txtDate.Text = DateTime.Now.ToString("yyyy-MM-dd");
}
}
Now, if you really don't want any kind of post back?
Then you have to start writing some JavaScript, and start making ajax calls to some web methods.
Now, a ajax call certainly is "less" of a post-back then a UP, which in turn is less of a full page post-back.
If you absolute have a "poor" page design in which a UP can't be used, then yes, you have to start writing and adding client side js code, and thus you can setup a ajax call, and no page post-back will occur. it is quite rare that a UP can't be used, but ajax calls are better, but they also take significantly more time to setup, write and adopt.
However, keep in mind that a ajax call to server code does not have any use of controls on the page. So, you have to return values, and then have your js code update the controls on the page.
So, if a UP can suffice, then that's the least effort. The fantastic part is you don't have to write up and wire up a whole bunch of JavaScript code in place of using that UP.
For sure, a ajax call is best, but that takes more code, more time, and has more moving parts (and requires JavaScript skills on your part). Often this extra effort and time (cost) can't be justified to adopt ajax calls for the page, so a UP is a good middle ground. it is somewhat of a compromise compared to ajax calls, but it boatloads of less work, and thus often a great choice cost and time wise. In other words, in most cases a UP is "good enough".
I have a fileupload control in Updatepanel. It only works when i register <asp:PostBackTrigger ControlID="btnAddPersonalInformation" /> in triggers but the problem is that it refreshes whole page which I don't want to. How to stop this full page upload. I also used AsyncPostBackTrigger but that also doesn't work i.e. doesn't upload file so the only way is PostBackTrigger but that refreshes whole page.
Use a ScriptManager along with the update panel control. ScriptManager should be placed before the UpdatePanel. You can refer MSDN documentation.
I have a Update Panel inside a User Control i use on 2 pages in my website
Both pages use the same MasterPage, ScriptManger is declared in the MasterPage.
Both pages call the UC the same way:
<uc:SearchCube runat="server" ID="searchCube" />
in the Update panel i have many RadioButtons that on change generate a server side event that fill dropdown in the update panel and update the panel
protected void SearchCategoryChanged(object sender, EventArgs e)
{
FillDropdowns();
SearchOptions.Update();
}
Update Panel is set like this:
<asp:UpdatePanel ID="SearchOptions" runat="server" UpdateMode="Conditional"
hildrenAsTriggers="true"/>
Each RadioButton is set like this:
<asp:RadioButton ID="RadioButton1" GroupName="SearchCategory" runat="server"
AutoPostBack="true" OnCheckedChanged="SearchCategoryChanged" Text="Text"/>
I also have an AsyncPostBackTrigger on each Radio Button Controller
The problem i have is that on one page when i call the Update() function the panel is updated and Page_Load is triggered which causes the UC to refresh and reload the default settings of the UC
I can see in DEBUG mode that on the working page Update() does not generate Page_Load.
Can anyone explain to me why this is happening?
Everytime a request goes to the server, it executes the Page_Load event.
What you need to do is make sure you have a PostBack validation on all your pages:
protectec void Page_Load(object sender, EventArgs e)
{
if(!Page.IsPostBack)
{
//Not a postBack: Normal page load
//Init your page here
}
else
{
//It's a PostBack (from a command).
//Do nothing or init stuff your all your commands.
}
}
If you put some breakpoints in your Page Load and your SearchCategoryChanged method, you'll be able to see what the pipeline looks like.
Fixed my problem.
the problematic page is an index page that takes a few parameters in.
I have a Response.Redirect() on the page to avoid duplication of pages.
Apparently when the PostBack() is made it calls the page without any parameters and i was forcing it to be redirected into a default view since no parameters were sent to the page.
i found a lead to my problem in a Microsoft help forum that stated:
By calling Response.Write() directly you are bypassing the normal
rendering mechanism of ASP.NET controls. The bits you write are going
straight out to the client without further processing (well,
mostly...). This means that UpdatePanel can't encode the data in its
special format.
Anyway the page was reloading every time which caused it to reload the User Control with it's default values.
In the website I'm working on, there is a bug I'm unable to figure out.
The bug is the following.
I have two different pages (with different functionality/controls). Both of them include the same page header that include a logout button.
<form id="Form1" method="post" runat="server">
<uc1:pageheader id="PageHeader1" title="XXXXX" runat="server"></uc1:pageheader>
<!-- page content goes here -->
</form>
The button is the following (located in pageHeader.ascx)
<INPUT type="button" value="Log out" id="btnLogout" name="btnLogout" runat="server" onserverclick="btnLogout_ServerClick">
With a server side function btnLogout_ServerClick that handle the disconnection.
In one of the page, the button is doing its role just fine.
In the other the btnLogout_ServerClick function is never reached.
I tried to put a breakpoint in the page_Load function of both pages. They both start with a first passage with the IsPostBack value set to True but after going through the loading of every control on the page, the first one end up in the log out function, whereas the other starts a new page_Load cycle with IsPostBack set to False.
There is no trace of error/exception on what could cause this behavior, if anyone could give a hand, either in giving a solution or providing a way to find the problem, that would be welcome.
And I know that I could try to remove every control and add one at a time to see if they prevent the button from working, but both pages have numerous control and it'd be nice if I could avoid that.
Use browser tools (IE dev tools, Firebug etc) to see if the posted data is the same in both cases. If there are any redirects check if other code is not doing redirect before the event is raised.
First thing I would check is the event handler for the button. Are you sure it is correctly registered ?
Possibly related to user control event handler lost on postback
I have an ASP.NET page with one control (.ascx) on it. The page (.aspx) onload assigns some text to a couple labels and passes a product ID to the .ascx control. The .ascx control, onload, takes that product ID from the .aspx page and hits the database several times, does several calculations, etc - basically takes a long time to load.
So when I'm clicking a link to this .aspx page, it is taking 7-10 seconds for the page to load. I've narrowed it down to the calculations on the .ascx control being the culprit and I've optimized the code as much as I can ... but it's still taking too long.
Is there a way to load the .aspx page BEFORE the control loads? (Maybe display a "Loading..." animation? Like used in an UpdateProgress?)
You could do this with an UpdatePanel. It will take a little trickery, but try something like this:
1) Put the UserControl in an UpdatePanel.
2) Put a public property on your usercontrol like IsEnabled that it will use to conditionally do nothing or render a "please wait." Set it false from your main page.
3) Add some code in OnInit to your main page:
if (MyScriptManager.IsInAsyncPostback) {
MyUserControl.IsEnabled=true;
}
4) Add a client script along these lines:
finished=false;
Sys.WebForms.PageRequestManager.pageLoaded(function(sender,args) {
if (!finished) {
finished=true;
__doPostBack('','');
// you can include the uniqueID of your updatepanel as the first arg
// otherwise it will refresh all update panels
}
});
or with jquery..
finished=false;
$(document).ready(function() {
if (!finished) {...
}
});
What this should do is cause an async postback to be initiated immediately after the page is done loading, which will in turn cause the update panel to be refreshed. Since you set it to be enabled when it's in an async postback, it will render itself the 2nd time.
The only possible way to achieve this is by setting it up as a separate HTTP resource. At the moment .NET is integrating the control into the page so that it is waiting unti it has everything it needs to respond.
You could do this a multitude of different ways:
Web Service that gets called via javascript
Seperate page which contains the control (and is hosted within an iFrame to appear to be on the same page)
The best way to do this would be to use an iFrame (or something similar) which will instruct the browser to request the control after the main page has been sent).
Personally, I would never use an iFrame to load content on a page - that's more like a hack than anything and plus, iframe == "bad".
But they are right, you won't be able to do anything like what you're looking for.
If the user control DOES NOT have any web controls that cause a postback (or have any form controls that you need to access during a postback), then I would use AJAX to request the data on the server after the page has already loaded and use javascript to display the content on the page.