[jcwrenParticipant]

One (hopefully) last question. In the jqxObservableArray callback, or in the source ‘updaterow’ or ‘addrow’ callback, is it possible to change another field in the same record?

For instance, I have a date, and if the date is earlier than today, I want to force setting another field to a specific value. In the OA callback, using this.set (change.index + ".flagged", "No") fires another callback with with everything as I expect it, but the grid isn’t updated, and the flagged field isn’t changed in the source’s ‘updaterow’ callback. I’m guessing this is because it’s internally turning off observation during the callback. So what’s the correct way to do this?

[jcwrenParticipant]

This jsFiddle (https://jsfiddle.net/jcwren/j9pyfq07/) is a simplified version.

The problem appears to be that having any object or array in the data triggers the exception.

In this example, simply changing a competitors name will cause it.

[jcwrenParticipant]

Perfect. And with the wonderfulness of jQuery, and some selective field naming, that boils down nicely to this:

$("[id^='ec-']").on ('focus', function () {
  $(this).addClass ('jqx-menu-item-top-hover-' + theme);
});
$("[id^='ec-']").on ('focusout', function () {
  $(this).removeClass ('jqx-menu-item-top-hover-' + theme);
});

[jcwrenParticipant]

It appears that it’s recalculating the drop-down filters for *all* the columns, rather than just the column that changed.

The grid rendering time is minimal, on the order of a couple milliseconds. With the example I provided, adding 20 to 25 milliseconds for each additional column is a LONG time, especially when there are only 5 possible choices per column, and 5 rows.

Most of the jqWidgets are pretty efficient, but the drop-down filter lists is an exception. Perhaps one of your engineers will run a profiler on it, and see where the slow-down is. It effectively makes DDL filtering unusable. A 700ms lag after changing a cell is extremely noticeable. Running through a grid changing ‘Yes’ to ‘No’ for a number of rows or columns becomes very painful.

If this can’t be improved, perhaps you have a suggestion for how to inhibit or defer the filter updating. I could possibly defer it until the mouse is idle for a few seconds, or the user pauses or clicks in the filter bar area.

[jcwrenParticipant]

This jsFiddle (http://jsfiddle.net/jcwren/jadh02qu/) demonstrates the exact problem.

Set “adult_label = ‘Adult 10′” and an “Uncaught TypeError: Cannot read property ‘toString’ of null” exception occurs (see explanation in original post).

Set “adult_label = ‘Adult'” and it works correctly.
Set “adult_label = ‘Adult 10x'” and it also works correctly.
Set “adult_label = ‘Adult_10′” and it also works correctly.

[jcwrenParticipant]

That is 3.8.0, and that issue *is* present.

[jcwrenParticipant]

The above fix I mentioned works for the text boxes, but not the drop-down lists.

In the code below, if i.jqxdataformat.tryparsedate(n) returns null, and ar is not set to true, then an exception is thrown on the ax.setHours(0), which is caught by the try/catch, and then tries to do an.toString() when an is null. The two following changes fix this (in part).

if (!ar) { –> if (!ar && ax) {

if (an.toString() != "") { –> if (an && an.toString() != "") {

There’s still an issue that if the drop-down list column has ‘Limited-10’, it’s being interpreted as a date, and won’t match any values in the column. If I change the drop-down label to ‘Limited Ten’, it now works correctly. It appears there’s *WAY* too much effort trying to interpolate everything into a date. That might explain some of the performance issues with large grids.

Function that’s throwing the exception:

try {
    var au = new Date(an);

    if (au.toString() == "NaN" || au.toString() == "Invalid Date") {
        an = i.jqx.dataFormat.tryparsedate(an)
    } else {
        an = au
    }

    ax = an;
    var ar = false;

    if (W != undefined && aa != undefined) {
        if (W.indexOf("t") >= 0 || W.indexOf("T") >= 0 || W.indexOf(":") >= 0 || W.indexOf("f") >= 0) {
            ar = true;

            if (am && am.toString().indexOf(":") == -1) {
                var ai = i.jqx.dataFormat.tryparsedate(am.toString() + ":00", aa);

                if (ai != null) {
                    this.filterdate = ai
                }
            }
        }
    }

    if (!ar) {
        ax.setHours(0);
        ax.setMinutes(0);
        ax.setSeconds(0)
    }
} catch (ao) {
    if (an.toString() != "") {
        return false
    }
}

[jcwrenParticipant]

FWIW, 3.8.0 seems to support 5 and 9 digit US ZIP Codes(tm), along with whoever uses 3-2-4 formatted codes.

/^(^\d{5}$)|(^\d{5}-\d{4}$)|(\d{3}-\d{2}-\d{4})$/

[jcwrenParticipant]

Excellent. I didn’t have different names, which I imagine was causing the problem.

Is there a class name available for the errors that jqxValidator and jqxGrid.validation uses, so I can render the tools tips in the same look, and have it follow any theme changes or updates to jqxWidgets?

[jcwrenParticipant]

1.5 years later, this method is still not in the documentation.

[jcwrenParticipant]

OK, still doesn’t work. I fill out the username, leave the email blank, click ‘Submit’, and the button has focus, not the email field.

 $("#jqxbutton").click(function () {
     $('#testForm').jqxValidator('validate');
 });

Is this not calling the validate method?

[jcwrenParticipant]

“This is the expected behaviour of the widget.” Wow. That is *so* wrong, and contrary to EVERY UI experience a user expects. When you select all text in a box, the user EXPECTS that it will be cleared, not maintain some state that has to be reset by re-typing a minus sign or something equally bizarre.

This is a defect in this control, without question.

You should probably re-read the UI guidelines for Windows and OSX. You’ll find that this is in no way an “expected behavior”.

[jcwrenParticipant]

Yes, that is exactly what I was looking for. Thank you!

[jcwrenParticipant]

I don’t want the user to be required to do that. A child widget should support a method to ask it’s enclosing parent widget to close the child cleanly. This should be able to be done by calling the jqxGrid’s ‘endcelledit’ method from inside the jqxDropDownList’s ‘close’ event, but this results in the jqxGrid firing another ‘close’ event to the jqxDropDownList, which results in a loop, causing a stack overflow.

Thank you,
–JC

[jcwrenParticipant]

That did the trick, thank you. Now, is there any way to trigger an endcelledit after they’ve made a selection from the drop-down list?

[Author]

Posts