We have a data field that is padded to four characters..
For example, you could have "ABC ", or "DEFG". This data is used as value of a select dropdown in the filter toolbar.
When the filter is being built, the padding is getting trimmed; so "ABC " is now "ABC".. so the filtering at the middle tier fails.. "ABC" != "ABC "
I modified the jqgrid source to remove the trimming, is this safe? It fixes my issue, but I'm not clear if I'm creating more problems.
/* the format of element of the searching toolbar if ANOTHER
* as the format of cells in the grid. So one can't use
* value = $.unformat.call($t, $elem, { colModel: cm }, iCol)
* to get the value. Even the access to the value should be
* $elem.val() instead of $elem.text() used in the common case of
* formatter. So we have to make manual conversion of searching filed
* used for integer/number/currency. The code will be duplicate */
if (cm.stype === "custom" && $.isFunction(searchoptions.custom_value) && $elem.length > 0 && $elem[0].nodeName.toUpperCase() === "SPAN") {
v = searchoptions.custom_value.call($t, $elem.children(".customelement").first(), "get");
} else {
//v = $.trim($elem.val()); // *** commented this out ***
v = $elem.val();
switch (cm.formatter) {
case "integer":
v = cutThousandsSeparator(v)
.replace(getFormaterOption("decimalSeparator", "number"), ".");
if (v !== "") {
// normalize the strings like "010.01" to "10"
v = String(parseInt(v, 10));
}
break;
case "number":
v = cutThousandsSeparator(v)
.replace(getFormaterOption("decimalSeparator"), ".");
if (v !== "") {
// normalize the strings like "010.00" to "10"
// and "010.12" to "10.12"
v = String(parseFloat(v));
}
break;
Thank you very much for the bug report!
It seems be a but, but one should skip $.trim better only in case of stype: "select". It will reduce side effects for other cases. I committed the changes to GitHub (see here).