Странная ошибка при объединении ASP.NET updatepanel с jQuery UI DatePicker

Общая проблема с комбинациями AJAX и jQuery заключается в том, что это ...

$(document).ready(function() {
       buildDatepicker();

Происходит только при загрузке первой страницы. Если вы замените область HTML, на которую повлияла buildDatapicker (); вы потеряли все связанные с ним события (даже если вы заменили его теми же элементами).

Все, что вам нужно сделать, это вызвать buildDatepicker для только что загруженного HTML ... и передать элемент, который был загружен только для того, чтобы убедиться, что вы не удвоились ...

$(document).ready(function() {
       buildDatepicker(document);
...

function buildDatepicker(element) {
    var dp = $("#datepicker", element).datepicker({
        onSelect: function(dateText, inst) {
            /* Do a postback when someone clicks a date */
            doAspNetPostback();
        }
    });
}    

Теперь вы можете вызвать buildDatepicker (myNewlyLoadedElement); для повторного связывания функции выбора данных.

Я исправил различные проблемы с асинхронностью в jQuery / Updatepanels, используя аргумент ScriptMode = "Release" в ScriptManager.

  <asp:ScriptManager ID="scriptManager" runat="server" ScriptMode="Release">
  </asp:ScriptManager>

You could try using datepicker to set an altField and check that for changes to do a postback.

Некоторое время назад я нашел другой сценарий, который я использую уже некоторое время и никогда не испытывал проблем.

 <script type="text/javascript">
        /*
        [__doPostBackAsync]
        Will send an async postback to the backend
        */
        function __doPostBackAsync(eventName, eventArgs) {
            var prm = Sys.WebForms.PageRequestManager.getInstance();

            //check first if the request queues have this item
            if (!Array.contains(prm._asyncPostBackControlIDs, eventName)) {
                prm._asyncPostBackControlIDs.push(eventName);
            }
            if (!Array.contains(prm._asyncPostBackControlClientIDs, eventName)) {
                prm._asyncPostBackControlClientIDs.push(eventName);
            }
            __doPostBack(eventName, eventArgs);
        }
    </script>

Вы по-прежнему можете вручную установить функцию обратного вызова, точно так же, как в приведенном выше сценарии.

Возможно, вам также придется вручную добавить обработчик ресурсов сценария (не могу вспомнить, какой именно), но я специально помню, что у меня были проблемы с вызовом async и неасинхронные посты. Надеюсь, это поможет.

Похоже на состояние гонки, попробуйте UpdateMode = "Conditional" и ChildrenAsTriggers = "false", ссылка .

Я попробовал ваш код для воспроизведения ошибки и могу воспроизвести ошибку. И я пришел к выводу, что есть проблема с jQuery / UpdatePanels.

Если я заменю кнопку LinkButton, вы увидите, что ссылка напрямую вызывает __doPostBack (...), ту же самую функцию с те же самые аргументы, которые вы вызываете. И нажатие кнопки ссылки работает напрямую, а щелчок по дате - нет.

Это означает, что внутри jQuery происходит что-то, что меняет некоторый контекст. Но я понятия не имею, что это будет.

Однако, если я перейду через код в FireBug работает достаточно медленно

А? Почему бы не дать ему секунду, чтобы разобраться?

setTimeout(function(){alert(sender._postBackSettings.panelID);},1000);

Мне понравился ответ Тима, окружающий идею о том, что вы должны использовать args.get_PanelsUpdated () в событии pageLoaded. Кажется, это подходящее средство для того, что вы пытаетесь сделать. Попробуйте - если не сработает, значит, у меня в рукаве есть еще одна идея (хотя и грязная).

Я подумал, что это интересно, если вы добавите предупреждение после doPostBack, тогда FF не вернет значение null.

    function doAspNetPostback() {

        __doPostBack('<%= hiddenOnSelectionChangedButton.ClientID %>', '');
        alert('<%= hiddenOnSelectionChangedButton.ClientID %>');
    }