I suppose that the problem will be solved if you would use
SetDatepicker(el);
instead of
SetDatepicker('input[name^="' + el.name + '"]');
UPDATED: Your jsFiddler demo had some bugs. Look at the modified demo http://jsfiddle.net/rUkyF/7/ and try to reproduce the problem. I see no problem.
UPDATED 2: I find that iJD found the origin of the problem. I wanted just to describe why modal: true disturbs working of jQuery Datepicker. I wanted that iJD award the bounty and I wrote the text below only for other reader which want to understand whether they should or should not use the options modal: true or jqModal: false.
If one uses modal: true option of editGridRow then the method $.jgrid.viewModal which displays the form will be called here with modal: true option and the option will be forwarded (see the line) to jQuery.jqm ($.fn.jqm) defined in module jqModal.js. As the result the L function is called with the parameter 'bind' in the line of jqm code. So the function L will bind (see the line of code) keypress, keydown and mousedown events of the document to the event handler m defined in the next line as
var m = function (e) {
var h = H[A[A.length - 1]],
r = (!$(e.target).parents('.jqmID' + h.s)[0]);
if(r) f(h);
return !r;
}
where the function f are defined in the like as
var f = function (h) {
try {
$(':input:visible', h.w)[0].focus();
} catch (_) {}
}
So we can see that the usage of modal: true follows blocking of all controls which are not parents of div with the class '.jqmID' + h.s ( typically '.jqmID1'). In the case the first visible <input> field of the form will get focus (because of calling of the function f).
It's known that many jQuery UI controls create elements (menus, datepicker etc) which are direct children of <body> (for example the Datepicker creates <div id="ui-datepicker-div"> which is direct children of <body>). So keyboard and mouse events could be blocked for such controls.
So you should not use modal: true option if you want to use some jQuery UI controls of some other controls inside of jqGrid forms.
By the way the default value of jqModal option of editGridRow is already true (see the documentation). So one can remove the jqModal: true from the current code like some other options of editGridRow. If one would use jqModal: false instead, the jqModal.js plugin will not used by editGridRow and the modal: true option will be ignored too. In the case the whole HTML page will be not blocked. The current grid only will be blocked by the corresponding overlay of the grid.
In my personal default settings which I use per $.extend($.jgrid.edit, {...}) the jqModal is switched off:
$.extend($.jgrid.edit, {
recreateForm: true,
jqModal: false,
closeAfterAdd: true,
closeAfterEdit: true,
... // other less common settings
});
You should decide yourself which default settings you want use.
UPDATED 3: I posted the bug report which suggest how the code of jqGrid could be fixed. If one changes the line
m=function(e){var h=H[A[A.length-1]],r=(!$(e.target).parents('.jqmID'+h.s)[0]);if(r)f(h);return !r;},
to the lines
m=function(e){
var h=H[A[A.length-1]],
r=(!$(e.target).parents('.jqmID'+h.s)[0]);
if(r) {
// e.target could be inside of element with absolute position like menu item
// in the case parents call above will don't find the modal dialog
// To fix the problem we verify additionally whether e.target is inside of
// an element having the class 'jqmID'+h.s
$('.jqmID'+h.s).each(function() {
var $self = $(this), offset = $self.offset();
if (offset.top <= e.pageY && e.pageY <= offset.top + $self.height() &&
offset.left <= e.pageX && e.pageX <= offset.left + $self.width()) {
r = false; // e.target is do inside of the dialog
return false; // stop the loop
}
});
f(h);
}
return !r;
},
then the problem should be fixed. The demo uses modal: true option and datepicker works in edit dialog. It uses the fixes which I described.
UPDATED 4: The bug fix, which I described in UPDATED 3 of my answer, is now included (see here) in the main code of jqGrid. So the versions > 4.4.5 should not have the described problem.
