Start Building Professional
Web Apps Today

grid filter incorrect after column move

Hi,

If a new header containing filters is attached to the grid after the columns are moved, the filter references to incorrect columns.

Original Column Name sequence: 0,1,2,3,4,5,6
Column sequence after move: 0,2,3,1,4,5,6 (Column 1 has been moved to between Columns 3 and 4) - value of "this._c_order[]"
Column filter reference: 0,3,1,2,4,5,6 (i.e. a filter on Column 2 filters data on Column 3; Column 3 filters on Column 1 etc.) - value of "this._m_order[]"

The issue seems to be rectified if Line#90 inside "dhtmlXGridObject.prototype._build_m_order=function(){" in dhtmlxgrid_filter.js is modified as follows:

original: this._m_order[this._c_order[i]]=i;
modification: this._m_order[i]=i;

I am not sure if this change will impact other functions. Please let me know the proper fix.

Thanks.

Situation confirmed. 
Mentioned code was created with scenario in mind, when already existing filters was moved with columns - in such case it works correctly. But it really fails when new header row attached after column moving. 

The modification, which you have described - allows to attach new row with filter , but will cause problems if existing filters was moved with columns. 

Unfortunately there is no easy way to force correct behavior in both scenarios, we will try to fix situation in next version, but for now, adding filters after column moving will cause incorrect results.. 

Thanks for the reply.

Just want to bring the following points to your notice. Maybe this would help you in suggesting an immediate solution.

Mentioned code was created with scenario in mind, when already existing filters was moved with columns - in such case it works correctly.

The original code works fine only when a column with an existing text_filter is moved. It fails when a column with existing select_filter or combo_filter is moved. (I did not test the other filters.)

The modification, which you have described - allows to attach new row with filter , but will cause problems if existing filters was moved with columns.

The modified code works fine when columns with existing select_filter or combo_filter is moved. It fails only when a column with an existing text_filter is moved.
Also, the modified code works fine for all the three filters when attached after column move.

Hence, after modification, the problem is only with an existing text_filter being moved. I feel there is a difference in the data extraction methods of a text_filter vs select/combo_filter. Is there a solution to handle the existing text_filter?

Thanks.

Please ignore my previous answer:

Thanks for the reply.

Just want to bring the following points to your notice. Maybe this would help you in suggesting an immediate solution.

Mentioned code was created with scenario in mind, when already existing filters was moved with columns - in such case it works correctly.

The original code works fine only when a column with an existing text_filter is moved. It fails when a column with existing select_filter or combo_filter is moved. (I did not test the other filters.)

The modification, which you have described - allows to attach new row with filter , but will cause problems if existing filters was moved with columns.

The modified code works fine when columns with existing select_filter or combo_filter is moved. It fails only when a column with an existing text_filter is moved.
Also, the modified code works fine for all the three filters when attached after column move.

Hence, after modification, the problem is only with an existing text_filter being moved. I feel there is a difference in the data extraction methods of a text_filter vs select/combo_filter. Is there a solution to handle the existing text_filter?

Thanks.

Your analysis The modification, which you have described - allows to attach new row with filter , but will cause problems if existing filters was moved with columns. is correct.

Thanks.

>>It fails when a column with existing select_filter or combo_filter is moved.
In latest dhtmlxgrid (2.0 81107 )  it must work correctly for plain column types ( there is a known issue with co|coro column types which fixed in dev. version - can be provided by request if necessary ) 

Hi,

there is a known issue with co|coro column types which fixed in dev. version - can be provided by request if necessary

I would much appreciate if you could send me the fixed version. Meanwhile I was able to fix the issue, for my use-case, for text, select and combo filters (though you may come up with a much cleaner solution).

Thanks.

Updated js files sent by email.