When setting the Page directive for MaintainScrollPositionOnPostBack to true on pages with CollapsiblePanelExtenders, the page does not properly maintain the scrolling position once a postback is made.
I've noticed that once the postback is made, the browser attempts to scroll to the original position before the collapsible panels are expanded again (as they are loaded in a collapsed state, and then expanded on the client side), and so the scrolling position either does not move at all or it makes it only part way.
One potential solution I can think of is to wrap the affected panels in an UpdatePanel to avoid the hard postback altogether, but this is not particularly ideal since this issue affects multiple screens.
You could capture the state of the CollapsiblePanelExtender into a HiddenField, then deal with the state of the CollapsiblePanelExtender serverside during the postback.
There are some examples here.
Related
I have recently been trying to figure out a problem on my C# ASP.Net webforms website and finally found the cause but no fix.
Explanation of the problem:
I have a gridview in an updatepanel. This gridview holds images uploaded by the user and also imagebuttons. The image buttons cause a partial postback. The postback carries out an action on a selected image and refreshed the gridview.
This works great until I tested in firefox. In Firefox after the partial postback, the page scrolls up to the top of the GRIDVIEW (not the webpage).
Cause of the problem:
The cause of the problem was because the div that contains the gridview has no set height value in the CSS. This cause the div to shrink back to zero when the Gridview is refreshed and in turn causing the current position of scroll to be non existent (well it is but not in the div) and thus bringing the page to the top of said div.
Fixes tried:
Tried setting the height of the DIV to 2000px which stopped the scroll but meant there was lots of excess space (not acceptable and this option can not be used as gridview size is dynamically changing)
Tried JS code to move the page back to position it was before the partial postback (Also worked but the scroll moved up and the JS moved it down. This looked very unprofessional)
Tried to setting the div to 2000px before a partial postback and then resizing it to fit it new elements in and end request... not successful.
I have a requirement where i have to render large number of Dropdown controls on page,number of items in dropdown varies and it can goes up to 1000 items(not my design but my client). I am using Telerik controls on my page. As the number of controls on page increases the performance decreases and browser starts lagging sometimes it stop responding and hangs. To make it more worst client want this to be supporte on IE browser.Even design change is not acceptable. Please have a look to attached image. I am struggling since long to clear this but no luck.
My functionality in brief: By clicking on Add link new row is added on page dynamically(postback, redrawing all the controls again). On value change of first dropdown (i.e. Field column) the controls in Value column changes(again postback and redrawing all controls)
I see you're using individual controls that cost a lot of resources, and there is no other way to avoid it, more controls, more resources are needed.
In my opinion you could use a RadGridView with embbeded Controls and play with the appearence to give it the same look and feel, if you do it well the client may not note the diference.
I am dynamically loading user controls to switch between views in my project. I am aware that I need to reload my user control on every postback. The odd thing is my viewstate for the control is maintained even though the control is gone? I confirm that the panel I loaded it into is empty and then I check the view state and my value is there.
What's stranger is that if I load a different control, it can see the viewstate from the previous control? I checked and my page cannot see viewstate from my dynamically loaded control and visa versa. This makes me think the user control is treated as its own page. The confusing part is why the second view I load can see values from the first and why the values are there even though I the control has disappeared?
I also find this section of the code to be useless. Why is it removing the control? The panel is always empty (the code is from Telerik):
string controlId = LatestLoadedControlName.Split('.')[0];
Control previousControl = pnlControlPlaceholder.FindControl(controlId);
if (!Object.Equals(previousControl, null))
{
this.pnlControlPlaceholder.Controls.Remove(previousControl);
}
I looked at several posts and most say that viewstate is lost on every postback, although this is not the case for me. Perhaps because I'm using update panels. Although if an intial request handles an event and then reloads the same control again, the viewstate is lost. It only seems to preserve the viewstate on the very next postback.
Can anyone explain this odd behavior of sharing viewstate between user controls or why it is there even though the control is lost?
Apparently you can read viewstate between pages in two scenarios... Cross page postback and when using Server.Transfer. I believe the cross page postback scenario would explain what I am seeing.
Yes, I realize that's a bit of a vague title but I'm having a hard time stating the problem. I have a .Net .aspx page that has a Master page, some Ajax, and an updatepanel. My problem occurs on 2 different pages but in both cases I'm either selecting a radio button or a checkbox when the behavior occurs. Immediately after selection the entire page moves down. It does not scroll but instead it is like an extra tag was inserted into the source. I have done HTML source comparisons before and after this change and nothing is different. I can only assume it is related to the updatepanel but I cannot determine where this may be happening.
I'd be happy to provide more information if you can direct me towards a solution.
Thanks!
I am not entirely sure if this will do it and there is not enough detail here to be sure, but have you tried setting RenderMode to inline on the UpdatePanel? Maybe that will do the trick. Otherwise go take a look at Fiddler and see what is coming back from the server. Alternate recommendation (if none of the above work) is to just get your result in Json and change the markup yourself with jQuery or something like it.
Incredible. This was exactly the problem. I've modified my code as follows and form stays in place after selection. This was a simple case of selecting a radio button and having it auto-populate a dropdownlist.
[asp:UpdatePanel ID="panelValidation" runat="server" ChildrenAsTriggers="true" UpdateMode="Always" RenderMode="Inline"]
[ContentTemplate]
[asp:ValidationSummary ID="ValidationSummary1" runat="server"]
[ContentTemplate]
[asp:UpdatePanel]
Thanks!
On a fairly complex page, we're getting some unusual behavior with dropdownlists in IE6. To layout the basic structure, there are 2 update panels on the page each with a GridView presenting a master-details layout. In addition to the grid, each panel houses some DropDownLists for filtering the data in the respective GridView.
Now what's happening is that a button on the bottom grid will cause a modal popup form to display, where some details about the row item can be modified. As per the ASP.NET AJAX JavaScript, the DropDowns disable during the postback, and re-enable after it closes.
The bottom grid also has a timer attached to it that periodically updates it to keep the view of the data fresh. When this timer ticks after the modal popup is closed, the drop down lists mysteriously vanish, except for the ones in that update panel which apparently get rendered again.
Oddly enough, if the timer ticks while the popup is up, the drop downs enable early and show through the modal (oh IE6...) but don't vanish later on.
Been a while since I posted this, but the problem occasionally resurfaces and I think I finally found an answer to it.
The AJAX Toolkit's modal popup javascript disables all DropDownLists on the page because they show through to the highest Z-level in IE6. But if something causes a postback while the modal is showing (like a badly managed timer) then the invisible state gets recorded into the viewstate for the DDLs.
One easy way around it is to just put the offending DDLs in an update panel, so they properly get refreshed on updates and don't get stuck. The more complex way is to ensure nothing causes extraneous postbacks while the modal is showing. The best way would probably be to ditch Webforms and all the baggage with it, but that's pretty much not going to happen.