Recent Posts

Pages: 1 [2] 3 4 ... 10
11
Please check this example:

https://paramquery.com/pro/demos/key_navigation

Code: [Select]
  editorKeyDown(evt, ui) {
      if (globalEditByPress) {
          let c1, r1;
          //check left and right key with key names
          if (evt.key == "ArrowRight") {
              c1 = this.getNextVisibleCI(ui.colIndx + 1);
              r1 = ui.rowIndxPage
          } else if (evt.key == 'ArrowLeft') {
              c1 = this.getPrevVisibleCI(ui.colIndx - 1);
              r1 = ui.rowIndxPage
          } else if (evt.key == 'ArrowUp') {
              r1 = this.getPrevVisibleRIP(ui.rowIndx);
              c1 = ui.colIndx
          } else if (evt.key == 'ArrowDown') {
              r1 = this.getNextVisibleRIP(ui.rowIndx);
              c1 = ui.colIndx
          }
          if (r1 != null && c1 != null) {
              this.focus({
                  rowIndxPage: r1,
                  colIndx: c1
              });
              this.Range({
                  r1,
                  c1
              }).select();
              return false; //to prevent default handing of keys b
          }
      }
  },
12
Brilliant - looking forward to seeing your custom implementation :)
13
That is an interesting requirement.

You are right: pqGrid doesn't differentiate how the editor is initiated, and there is no example for this specific dual-mode behavior currently.

I am looking into a customizable solution for this. If it works cleanly, I will provide you with the custom code shortly; otherwise, we will look into implementing this natively in an upcoming version of the grid.
14
Both Java's JTable and Excel, has semantically identical behavior when it comes to cell-editing and behavior of arrow keys, which differs from PQGrid.
In JTable/Excel, there is kind of two different edit-modes.
1. In which you start typing directly overriding the existing value
2. Init editing through double-click or typically F2 key

In first case, any arrow key pressed, commits the edit and moves cell selection in the pressed keys direction.
In the second case, the arrow keys provides no escape mechanism, but only provide caret position control

PQGrid by default uses a mixed of these approaches, where arrow keys UP/DOWN always provides this commit/move operation, while LEFT/RIGHT always provides caret control.
Is there some setting for PQGrid which affects this behavior or would I have to manually implement this or is there already some working example, still using custom code?
15
Help for ParamQuery Pro / Re: Change background color for Editable cells
« Last post by paramvir on June 03, 2026, 08:57:35 pm »
Please check the styling section of this example:

https://paramquery.com/pro/demos/readonly_cells
16
Help for ParamQuery Pro / Change background color for Editable cells
« Last post by vijay on June 03, 2026, 05:36:23 pm »
We want to apply a background color to editable cells and implement this logic at a generic level rather than configuring it for each individual grid.

In pqGrid, the `editable` property can be defined in two ways:

1. Directly as `true`
   editable: true

2. Conditionally based on row data

   editable: function (ui) {
       if (ui.rowData.isLocked == 1) {
           return true;
       }
       return false;
   }

Could you please suggest a generic approach to identify editable cells and apply a background color accordingly, regardless of how the `editable` property is defined?
17
It sounds like the issue may be related to outdated or incompatible frontend assets after the upgrade. Please try the following steps:

1. Update CSS files 
Make sure you’ve replaced all older ParamQuery CSS files with the ones from version 11.1.0. Missing or outdated styles can affect drag-and-drop visuals.

2. Verify dependencies 
Check that your versions of jQuery and jQuery UI are compatible with ParamQuery v11.1.0, as mismatched versions can cause UI issues like this.

3. Clear browser cache 
Perform a hard refresh (Ctrl + F5) or clear the browser cache to ensure the latest CSS and JS files are loaded.

After these steps, the column drag preview should display correctly while grouping.

Let me know if the issue persists or if you need help verifying compatibility.
18
Hello,

I have updated paramquery from v9.0.2 to v.11.1.0. After the upgrade, while grouping grid by column, I cannot see column name been dragged along with mouse cursor. It feels like after grabbing column name I am moving only cursor without column name. The column name becomes visible once it is dropped in the grouping zone and and grouping also works fine.

Can you please help on fixing this issue?

Do let me know if you need more information

Thanks
19
Thank you for reporting the issue.
20
Uncaught TypeError in cKeyNav.bodyKeyDown when typing in an empty grid with groupModel enabled (v11.1.0)

Description:
When groupModel is active but the grid currently contains no data (empty dataModel.data), clicking on the grid body to give it focus and typing any character on the keyboard causes a fatal Javascript exception.

Steps to Reproduce:
  • Initialize a pqGrid (v11.1.0) with groupModel enabled.
    Ensure the grid has no rows (dataModel.data: []).
    Click inside the empty grid body so it gains focus (the .pq-focus-mgr element).
    Type any alphanumeric key.

Expected Behavior:
The grid should quietly ignore the keystroke since there are no rows to navigate or jump to via Keyboard Navigation.

Actual Behavior:
The internal keyboard navigation ($.paramquery.cKeyNav.bodyKeyDown) intercepts the keystroke and attempts to jump to a row starting with the typed character. It triggers a selection event but fails to verify if the row actually exists before trying to read the pq_gtitle property of an undefined object, resulting in a crash.

Error Trace:
Uncaught TypeError: Cannot read properties of undefined (reading 'pq_gtitle')
    at $.<computed>.<computed>.<anonymous> (pqgrid.min.js?v=11.1.0:752:459)
    at handleListeners (pqgrid.min.js?v=11.1.0:39:329)
    at _pq_.trigger (pqgrid.min.js?v=11.1.0:41:19)
    at $.paramquery.cKeyNav.bodyKeyDown (pqgrid.min.js?v=11.1.0:335:462)
    at fn.onKeyDown (pqgrid.min.js?v=11.1.0:195:239)
    at HTMLDivElement.<anonymous> (pqgrid.min.js?v=11.1.0:195:403)
    at HTMLDivElement.dispatch (jquery-4.0.0.min.js:2:37917)
    at v.handle (jquery-4.0.0.min.js:2:35897)

Proposed Internal Fix (for pqGrid core):
In cKeyNav.bodyKeyDown or the internal row iteration logic for grouping, ensure rowData is defined before evaluating rowData.pq_gtitle or rowData.pq_gsummary.

Temporary Workaround / App-Level Fix:
For anyone else experiencing this in the meantime, you can bypass the crash by attaching a capture-phase keydown listener to the grid container to kill the event before cKeyNav can intercept it:

Code: [Select]
// Bind this immediately after initializing the grid
gridContainer[0].addEventListener("keydown", function(e) {
    var gridData = $(this).pqGrid("option", "dataModel.data");
   
    // Is the grid totally empty?
    if (!gridData || gridData.length === 0) {
        // Allow typing in external inputs/filters, but block empty grid body key navigation
        if (!$(e.target).is("input:not(:checkbox), textarea, select") || $(e.target).hasClass("pq-focus-mgr") || $(e.target).parent().hasClass("pq-focus-mgr")) {
            e.stopImmediatePropagation();
            e.stopPropagation();
        }
    }
}, true); // useCapture = true
Pages: 1 [2] 3 4 ... 10