External Tree checkbox filtering for exclusive rows for grid


Scenario: Dhtmlx 5 tree with Dhtmlx 7 grid

I am trying to filter only the checkbox items in a large dataset after it has been populated initially on page load.

Right now if I select a few check boxes it filters what was checked…but when i want to filter on the actual grid it includes the original 32k rows behind the scenes even though the grid view only shows the let’s sat 1200 rows returned from the checkboxes. Is it possible to have a grid only filter what was populated by the checkboxes? For example if I filter out a few rows with checkboxes and I know there is no value in these rows but is in the original rows…it filters out those rows which is very confusing. So, I looked through the documents and it seemed the add/smartfilter is what i needed…well, it does not break anything…but it has the same results as original code.

Is it possible to do what I am asking? - Please advise - thanks

  1. grid on load is populated by json data (variable computers) from external file (32k rows)

    var computer_grid = new dhx.Grid(“comp_grid”, {
    columns: [
    { width: 150, id: “unit”, header: [{ text: “Unit” },{ content: “selectFilter” }] },
    { width: 150, id: “computer”, header: [{ text: “Computer”},{ content: “inputFilter” }] },
    { width: 225, id: “model”, header: [{ text: “Model”},{ content: “selectFilter” }] },
    { width: 125, id: “serial”, header: [{ text: “Serial”},{ content: “inputFilter” }] }
    ], data: computers

  2. There is a tree object that has a list of checkbox ids that can be used to filter grid externally:

    myTree_Tab_02_Cell_A = myLayout_Tab_02_Cell_B_A1.cells("a").attachTree();
  3. There is an oncheck event for the tree in which uses a loop to iterate checkbox values to filter grid:

      computer_grid.data.filter(function(item){ for(var i=0;i<a1.length;i++) 
     						if(item.unit.toString().indexOf(a1[i])!=-1) return true; 
                                                  return false;
                                             }, { add: true,    smartFilter: true   })   });


I’m hoping I understand correctly what you’re trying to do, let me see if restating it sounds correct:

  1. Grid has 32000+ rows of data loaded into grid.data object.
  2. When items are checked in the tree, it applies a filter to the grid.data object, so only corresponding rows are shown.
  3. When you try to filter the grid directly (through header content item, such as inputFilter?) it’s returning rows based on all the original rows, not the items already filtered.

If this is the correct situation, then I think the issue you’re running into is that filtering via header rows ignores/replaces existing filter settings and only combines the filter rules set within the headers. Unless a setting for the grid already exists that I don’t know about, changing this behavior involves a development change, and I would expect that level of change to take quite a while.

I see 2 options for now:

First, you could load the data into a standalone object, and then repopulate the grid with only the items as filtered by the Tree. Then filtering the grid directly would only operate on the rows that meet the filter rules imposed by the Tree. This involves some memory overhead from maintaining one or more data objects, but it may take less processing to do the grid filtering on fewer data rows.

The second option (maybe) is to use the filterChange event of the Grid. You’d have to do some tests to see if it fires before or after the filter is applied to the Grid. If it’s after, you could use that event to call the filtering function currently being run by the oncheck event of the Tree. In effect, you would let the Grid run its own filter, and then (using the “add” and “smartFilter” settings) you would apply the extra filtering based on the checkbox status of the Tree.

If the Tree isn’t expected to change much (i.e., it’s set once after the page loads, it doesn’t change and all other filtering is done via the grid), I would probably choose to go with the first option because you wouldn’t have to keep reapplying the same filter over and over on thousands of rows; that could be a significant performance impact. But that all depends on how you use the page, so I leave that to your determination.