I have a DIV in which I have a asp:repeater which, based on data, puts information in this div. I then use Jquery's UI dialog to display the data to the user via a button click. This all works swimmingly.
So, I want to be able to add records to the data which populates the repeater. I have another part of the screen where people can enter this data, and it is saved to the database using an ajax call. This, too, works swimmingly.
I then want to update the data on my dialog box, without having to do a full postback to the server. So, this is normally pretty easy. I put my div into an UpdatePanel, and from Jquery initiate a __doPostBack. which then refreshes the data, which too, works swimmingly up to a point.
Once the __doPostBack is complete, the div is no longer hidden. It is now displayed on my page (with the updated data mind you), but the javascript i use to show the dialog, now no longer works.
Some investigation shows that:
On initial load of the page, the javascript which tells jquery to create a dialog from a div takes the div from wherever it is on the form, and appends it to the body element.
When the update panel posts back, the div is recreated, but the javascript to turn it into a dialog either isn't executed again (which I can understand... we haven't done a full load of the page, so the javascript doesnt execute again.
This means that the div is no longer a 'dialog' but a simple div on my page, which is not what I want.
So, my questions are is:
Is there a way of injecting javascript aftr the updatepanels postback which will execute and create the dialog properly again?
The solution would be not to use Updatepanel at all and just change the innerHTML of the div with data received through a jquery ajax call.
I found another solution to this. I put the dialog initialization javascript in a separate function called SetupDialog instead of being inside the $(function () { }); block.
Then I used ScriptManager.RegisterStartupScript in Page_Load to register the script so that it runs every time the Update Panel updates:
ScriptManager.RegisterStartupScript(this, GetType(), "SetupDialog", "SetupDialog();", true);
In this case, the dialog will only work after the UpdatePanel has been updated. If you need the dialog before that, then you can call SetupDialog inside the $(function () { }); block as well.
Related
I have a situation where I am loading an iframe inside of a backbone view. The view has an events hash that handles click events.
events: {
'mousedown': 'toggleActive'
}
This works fine for the DOM that the view is part of. Problem is when I click inside the iframe DOM, the click event doesn't bubble up to the view (as expected). So I wrote some code that transfers the click from the iframe DOM to the parent DOM. I have the following inside the iframe body.
$("body").bind("click", function(event){
window.parent.document.$("#"+tgId).trigger(event.type);
});
This works fine for regular jquery event handlers, but for some reason it doesn't trigger the view's event handlers (from the events hash).
Does anyone have any ideas?
Have you tried adding a debugger statement inside your click handler, and then checking what window.parent.document.$("#"+tgId) actually is? It's hard to say for sure, but my guess is that that code is not selecting the element you expect. jQuery will then happily let you call trigger on an empty set, so you would't get any errors if that was the case.
I'm using jQuery to convert a column of hyperlinks within a gridview into UI dialogs.
This gridview is in an updatepanel, and for one of the dialog's buttons I perform a __dopostback on this updatepanel, which refreshes the changes I've made within the dialog.
It all works rather nicely, apart from one small issue.... that is when the updatepanel posts back and recreates the gridview table with new data.. I lose the dialog functionality!
Previously, I simply had the following:
$('a.createdialog').click(function(e) { <iframe code here>.dialog( { <buttons and other options> } )
and it made sense that, once the gridview was updated, the above will essentially be wiped.
So I put that code into a function, and as well as running this function on the page load I also placed the function into the dialog's button code. This however does not fix the issue... I tried moving where I call this function around from the button to the updatepanel's loading events with registerstartupscript().. again no luck.
any ideas?
Cheers :D
Try the live method, description from JQuery Docs: Attach a handler to the event for all elements which match the current selector, now and in the future. The async postback/refresh is killing the handler; live can help in this situation persist the handler.
http://api.jquery.com/live/
$('.clickme').live('click', function() {
// Live handler called.
});
HTH.
I was hoping for a little help. I am currently using some of the jQueryUI widgets in an ASP.Net Web App. I have successfully got everything working. Basically, I have a GridView on a page which contains some hidden fields in each row containing data. I also have a dialog div containing an update panel and a few Labels.
When a user clicks on an Image Button on the GridView, the jQuery is fired to show the jQueryUI dialog and code behind is used to fill the labels from the selected GridView row. Unfortunately, the AJAX communication takes quite a bit longer to update versus showing the dialog div.
The same question actually applies to the loading of an ASP page into a jQuery popup window also as I will need to eventually do this.
So my questions are:
How can I make jQuery wait to execute until after the partial postback has returned with the AJAX information for the popup?
Is the above method the right way to go?
Is there a better way?
Is there a way to speed up AJAX
communications to make it more
instantaneous?
Thanks in advance for your input.
without knowing exactly what you're doing (code wise), the best I can understand is that you want to trigger some behavior after the ajax call has completed, which is actually supported like so:
$.ajax({
url: 'myurl.aspx',
success: function(data) {
//everything you want to happen after the ajax completes.
//this can either be code, or a call to another function that loads your div
}
});
I have a ListView on a page that displays a list of widgets. When a user clicks on one of the items in the list, I want to display a ModalPopup that contains controls allowing the user to operate on the item they selected.
I could easily accomplish this by placing a Panel and a ModalPopupExtender in the ListView's ItemTemplate, but this mean one set of hidden controls for each and every widget, which would massively bloat the page size. (There are going to be some rather heavyweight controls in there.) Instead I want to reuse a single ModalPopup for each of the widgets in the list.
I've done some searching but I haven't found anything that applies directly to my situation before. From what I've been able to figure out, however, I have to do something like this:
Place a Panel and a ModalPopupExtender on the page inside an UpdatePanel.
Build a custom WidgetManipulator user control that has a WidgetID property. Put this in the Panel, along with a couple OK/Cancel buttons.
In Javascript on the page, attach a click handler to each widget in the ListView that triggers a postback on the UpdatePanel.
On the UpdatePanel_Load event on the server, display the ModalPopup and then set the WidgetID propety on the WidgetManipulator to the ID of the clicked widget.
On the OKButton_Click event or CancelButton_Click event on the server, hide the ModalPopup. If OKButton was clicked, call WidgetManipulator.SaveChanges() first.
The part I haven't figured out is: How the heck do I know what widget was clicked on, and how do I pass that back to the server when I refresh the UpdatePanel? Is this even the right approach at all?
If you can use jQuery instead you could do something along the lines of these two posts:
Modal Delete Confirmation Version
Two Using jQuery SimpleModal Plugin
Demo
Inserting Content Using
jQuery SimpleModal Plugin Demo
When I need to pass data from client to server in ASP.NET AJAX, I generally use an asp:HiddenField with runat="server". Both can see it freely, but beware potential postback asynchronicity.
Sounds like you need to notify the server the widget was clicked - You may use a Timer to postback; or I'd go with option 5.
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.