I have a page that if IsPostBack is true, calls a javascript function which gets the size of the screen, passes the width and height to hidden fields and clicks a button to cause a PostBack. So I can retrieve the size of the user's screen and then load the page with default data with tables the right size etc.
Invariably, when the page (having posted back once) displays the data, a gridview is populated. Each row has a 'delete' Link Button in it. Each Link Button is set OnClientClick to call a javascript function to confirm you want to delete.
Above the grid is a row of text boxes / buttons / dropdownlists which allow you to search for, or filter the data showing. The Gridview is in an update panel. When the page first loads its data, and shows the list of projects, the delete Link Buttons all work okay. In every row, no problem. The Confirm box is displayed and, if Okay is selected, the asynchronous postback occurs.
If, after the initial data is displayed (which is already after one postback) you then use the search box and button, or use a dropdownlist to filter the data (the Search button and filter DropDownList are async triggers for the UpdatePanel) the data refreshes okay (always) but, then, sometimes, the 'delete' LinkButton in each row of the GridView does nothing. It doesn't even fire the ClientSide function. It's as if it is dead.
I had a similar problem a while ago with ImageButtons and the received wisdom seems to be 'change them to LinkButtons'. But I have dozens of grids with 'delete' LinkButtons that work okay, but this one has decided to stop working - sometimes.
I have to say, since moving to Framework 4.0, I'm thinking of giving up on UpdatePanels. Seem to have nothing but problems with sites that worked reliably for years in Framework 2.0
Any ideas please? Is this anything to do with the order in which controls are loaded on the second postbacks?
Edit: There is a twist to this. When this situation occurs, i.e. clicking on the Delete link does not even trigger the Client Side event - if you click on an area of the page outside the Gridview (i.e. outside the UpdatePanel) - and then click back on the Delete link - it works!
Regarding ImageButtons: There is a bug with IE10: ASP.NET fails to detect IE10 causing _doPostBack is undefined JavaScript error or maintain FF5 scrollbar position ( http://www.hanselman.com/blog/BugAndFixASPNETFailsToDetectIE10CausingDoPostBackIsUndefinedJavaScriptErrorOrMaintainFF5ScrollbarPosition.aspx ). Just upgrade to .NET 4.5.
Regarding LinkButtons: Do you have "ID" property? I remember I had a similar issue because my linkButton didn't have an ID.
Could you post some code? It would help.
Related
I know this is a problem that's been asked a few times before, but having had a look around I can't seem to find an answer that works for me.
I have a VB.NET page with 2 textboxes (set to show dates using JQuery), a dropdownlist and a datagrid.
Both textboxes and the dropdownlist are set to fire events, if they're changed, to update the datagrid.
Generally this works fine with one exception; when I change the value of either the textboxes or the dropdownlist after the initial page loading it often doesn't fire the event, the postback is set to false and the dropdownlist value is cleared; this doesn't happen in Chrome and is less frequent in Firefox than in IE.
I've tried the following:
I've set autopostback=true on all items
Tried adding an extra item, which isn't enabled, to the dropdownlist
Moved the boxes/List outside the update panel
Set ViewStateMode=Enabled
Tried adding a hidden field which is set to Request.Form(ddlDropdownList.UniqueNumber) and comparing it to Request.Form(ddlDropdownList.UniqueNumber) in the page load as a way to fire the event (the suggestion says to use Request.Forms, but this isn't coming up as an option on intellisense?)
All of these solutions either don't work, cause other issues, or I'm not doing them right (Which could certainly be the case)
Thanks in advance for any help you can give.
I don't know if this will help, it's been a while since I've done web forms, but I do recall there being a problem with listboxes where I had to check if the page was not on a postback when populating it.
So basically in your page loading method, check to see if the page is not a postback before initalising it. I found that even though I selected a new item, it was resetting the list back to it's default state.
This may or may not help you, but I thought it was worth at least mentioning it.
This project has gone from being a simple '99 Ford F-150 to the Homer.
I've got controls with a gridview with textboxes for data entry.
All the user controls on the pages are in AJAX updatepanels.
User types in a database column or budget entity or some other financial thing they want to include in the report.
The textboxes in the gridview have autopostback = true set.
overly long background info
When the user leaves the textbox, during the postback (triggered by onTextChanged) I do some validation back on the server on their entry - regexs, do they have rights to that column, is that column locked, etc. If it fails, I put a error message next to the textbox. If it passes, I wipe out any title or error that used to be next to the code.
Focus is getting lost from the postback if they're tabbing out of the box, rather than going to the next textbox in the gridview.
So to fix that I need, if their leaving the tb via the tab key, to also figure out what textbox or gridviewrow they're on, if they're not on the last row, and after the validation and labeling, put the focus on the textbox in the next row.
I can't figure out how, in ontextchanged, to find what caused me to leave the textbox, so I'm thinking use javascript onkeyup to test the key pressed and then find the next box etc, but the ontextchanged fires first and then the js never does, and also, since the control is all AJAXed, the javascript can't find the textboxes because when you enter the page everything is collapsed (the requirements people loooove to collapse and expand things), and so when it's expanded, all the 'new' textboxes are up in the viewstate stuff in the page source, and not down where javascript can see them.
The questions
So I'm wondering if I can have an onblur in the javascript that can trigger a postback where I can do my validation and such, and either 1) include the keypressed or pick it out of sender in the event or 2) followup the onblur with onkeyup and somehow figure out what textbox is next on the grid and throw focus there.
Or, is there another .NET based approach that could work for this? In terms of tearing the whole thing down and starting from scratch, I couldn't sell that to the bosses, I'm past the point of no return as far as that goes.
Does changing the one textbox value change anything else on the screen besides the error message/title associated with the textbox?
If not, my first thought would be to stop using the AutoPostBack and change to a Page Method hooked up to the onblur event. This should fix your tab issue and also reduce the back and forth between client and server.
Here's a blog post that talks about update panels and also Page Methods; The blog also includes a lot of useful posts about using javascript with .net, ajax, etc.
In a ASP.NET application I have a paging RadGrid which shows up textbox in each row. Outside the grid, there is an OK button to save the content of all the textbox. If user changes text in any one or more of the textbox and without clicking on the "OK" button, tries to move to a different page number (of the grid by clicking on the page number), he should be prompted for confirmation of save or cancel the changes.
I am guessing that one can write a Javascript function which would look for any form input control (textbox in my case) and detect changes and If there are changes, would prompt the user. However, I am not sure where I can call this function from? Any suggestion on this or a better way to achieve this would be appreciated.
I am using RadGrid but I guess this should be applicable to GridView as well.
I am not sure if this will help exactly but it might at least give you an idea:http://www.codeproject.com/KB/ajax/ajaxdirtypanelextender.aspx
I selection page that has a gridview that presents the user with a list of data items that they can click on to "drill into" - redirecting them to the data maintenance page.
Because the list can get long, we have a series of check boxes and drop-down lists at the top that act as filters.
We just implemented an UpdatePanel with an UpdatePanelAnimationExtender so that when the page made long trips back to the databse, they would get a nice "Processing..." pop up.
Problem is, this seems to break the viewstate on the drop-down lists and check boxes. Now, when they go to the 'detail page' and hit the BACK button to get back to the 'selection' page - the selected values in the checkboxes and drop-downlists are back to their initial defaults. The lists are still populated, but they 'forgot' what they had when the user clicked to the data maintenance page.
I took out the .aspx code for the UpdatePanel and the animation extended and retested and everything worked perfectly. So, apparently, the UpdatePanel and/or the AnimationExtender doesn't play nice with the viewstate.
Is there a way I can stop the UpdatePanel's actions from, in effect, zeroing out the '.SelectedValue" properties?
First I would remove your "filtering" controls from the UpdatePanel. Assuming that the data for these controls are valued on Page_Load, they do not need to be refreshed every time the filter is applied to the GridView. Only the GridView is being refreshed, so it's likely that it is the only control that should be contained in the UpdatePanel.
Each of the filtering controls can be added as a trigger for updating the UpdatePanel by declaring them in the section of the UpdatePanel control. Or, if the filtering process is invoked by a "submit" like button, that would be the control to be declared in the section. This should retain the values of the filtering controls in the browser's cache.
You can also try Nikhil Kothari's UpdateHistory control (Nikhil has an excellent blog, btw) which will save the contents of the UpdatePanel as history entries in the browser's history list.
EDIT: FYI, UpdatePanel does not "kill" ViewState. The ViewState is transmitted back and forth via the UpdatePanel's update mechanism, often causing performance issues if the ViewState is excessively large. What you're seeing is the browser's history cache not storing the values that have been updated on successive callbacks. The above techniques should help.
I've got a web application working using VB and Ajax. I'm using updatepanels to avoid the irritating "flicker" on postbacks to the server.
I would like to have a button control defined within the updatepanel itself (tried moving it outside and got some catastrophic error, so left it there) that makes the current panel not visible and a sibling panel visible. This works with the exception that the button must be clicked twice. Not double clicked, but clicked once than clicked again.
In setting breakpoints I discovered the code behind that's attached to the button is actually being executed on the first click, but the panels don't switch as expected. If I click the same button OR worse yet, a different button, the expected behavior of the second panel appearing occurs. However, with the second button being clicked there's an unwanted bonus of a third panel being displayed, the third panel being made visible due to the second button being clicked.
I'm assuming this behavior is due to the updatepanel and its Ajax nature. Is there a way to avoid the second click? Am I misusing the updatepanel? I really wanted to use a modal popup (right out of the AjaxToolKit) but had problems with posting back the data so I opted for this approach. Any insights, assistance, even criticism would be welcome as this has plagued me long enough. Thanks
If you get rid of the UpdatePanels do things work as expected with PostBacks? Chances are something in your Page_Load or other event higher up the chain are "resetting" things in some way before it gets to your click event. Could this be the case?
I think your problem is that only the update panel is receiving data from the server after the method executes. The panel your are trying to change is outside of the update panel so it does not know that its properties have changed.
You either need to do a full page postback or have the panel you wish to modify inside the update panel.
I have run into this before and resolved it, I just can't remember how. I will try to find my old code and get back to you. one thought, do you have EnablePartialRendering enabled in your scriptmanager? maybe try wrapping both containers in a third panel.
Your update panel is sitting inside the other panels.
Should that be the other way around? AFAIK only controls within the update panel will get updated in via the AJAX call.
Here's a fairly simple solution. (I was having the same problem this morning.)
The UpdatePanel can't render stuff outside itself. So, as you noticed, the updates are happening, but you're not seeing the result.
The easiest solution is to force a full postback. You can do that like this:
protected override void OnInit(EventArgs e)
{
var scriptManager = ScriptManager.GetCurrent(this);
// or this.Page in a UserControl, etc.
scriptManager.RegisterPostBackControl(someButton);
scriptManager.RegisterPostBackControl(someOtherButton);
// etc. for each control that needs to update something outside the UpdatePanel
}
This still allows the buttons themselves to be updated in the UpdatePanel by Ajax (e.g. changing their state to disabled or enabled). The full postback only happens if the buttons are clicked.
Like others have said an update panel only updates its contents, thats one of the main benefits of using it.
Panel2 and pnlPrvCmt need to be inside your update panel for your button click method to work. Another option would be to put Panel2 inside one update panel and pnlPrvCmt inside a second update panel. Then any control inside either update panel will cause both to refresh, as long as the UpdateMode=Always (which it is by default).
Try giving the dynamic control an ID when it is created. For some reason this is required by .net for a dynamic control to work in this context.
myControl.id="newID"
I have found this to occur under 2 different scenerios:
No ID set on the control. Either the ID is left off of the markup or the the ID was not set when a dynamic control was created. ASP.Net uses the ID to track actions.
Nested UpdatePanels. Scenerio: When using a Masterpage, you might have a content placeholder that you wrap in an UpdatePanel so that an UpdatePanel is not needed in the content on the page. Then, in developing your page you might, as a habit, add an UpdatePanel.