[mattcashParticipant]

The link button did not work…

The working example is at: https://www.jseditor.io/?key=chrome-issue

[mattcashParticipant]

I am not sure if I explained adequately the needs in our app. We are required to continue the natural flow of TAB into the grid at the bottom of the screen, starting at the the first cell in the first row and continuing forward. This forces us to have to know when we are leaving the last non-grid input (preceding the grid) and force the focus on the grid – first row – first cell, and then allow TAB to iterate the cells on that row. This, and the inability to use tabindex, is what led to our issue.

For now, I have overcome the obstacle with the following code:

    function forceTabToGrid(element, grid, cellname, index) {
        var $element = typeof (element) === "object" ? $(element) : element.indexOf("#") != -1 ? $(element) : $("#" + element);
        var $grid = grid === null ? null : typeof (grid) === "object" ? $(grid) : grid.indexOf("#") != -1 ? $(grid) : $("#" + grid);
        var $cellname = cellname;
        var $index = index || 0;

        $(document).on('keydown', function (e) {
            var $focused = $(':focus');

            // element is a jqxDateTimeInput object
            if (e.type === "keydown" && e.keyCode === 9 && $focused.parent().parent().hasClass('jqx-datetimeinput')) {
                if ($focused.parent().parent()[0].id === $element[0].id) {
                    $grid.jqxGrid('selectcell', $index, $cellname);
                    $grid.jqxGrid('focus');
                };
                return false;
            };

            return false;
        });
    };

Which can be called like this:

forceTabToGrid($transactionDate, $testGrid, 'firstColumnName')

This is my quick attempt at parsing out what type of jqx input is fired and it’s original id, and it seems to work nicely.

I am still curious, however, if there is a better approach – perhaps a solution more native in jqx?

[mattcashParticipant]

@dpibt,

We have had the same issue for quite a while. We just upgraded to version 4.5.3 (2017-June) and it appears to have been resolved! Good luck!

[mattcashParticipant]

Hello,

I was wondering if there was a way to correct this, or if there was possibly a fix coming in a future release? If not, is there an alternate route to take on disabling the cell of a column of multiple rows based on logic at the time the cell is entered?

Thanks!

[mattcashParticipant]

Hello,

I did not realize this question had been responded to. The solution you provided to janets does work for us. I have to thank janets as well for pointing me to the Bootstrap influence in this issue. We now understand why this is happening to us in the first place!

Thanks!

[mattcashParticipant]

Thank you very much for the suggestions. The setTimeout idea does appear to work, but we are uncertain of the consistency of the defined timeout always being long enough to allow for the grid to complete its work before we call ‘begincelledit’.

We do like the functionality of the Ever Present Row as well. We are searching for a way to validate the data inside the Ever Present Row BEFORE it is added to the grid as a new row, but have not found a way to do so through the API. Can you tell me if this is possible? For instance, is there event or callback performed when the user presses the “Add” popup or presses the Enter key that we could listen for?

Thanks!

[Author]

Posts