Hi,
I would like to save filters in a custom structure within a database.
I know I can intercept the FilterApplied event and inspect the filter structure and get the information needed to save it in the DB.
But it would be very useful for the user to be able to decide whether or not to save the filter, just through the functionality you provided, but redirecting the saving to the DB.

Is there a way to do this?
Could this be a future improvement?

Do you want to redefine the behavior of the Save Grid Filter/Restore Grid Filter commands in the filter box's Tools menu?

Theoretically we can provide 2 corresponding events for that - say, BeforeSaveGridFilter and BeforeRestoreGridFilter. They can have a Boolean parameter like DoDefault to enable/disable the built-in functionality.

Or it can be a new Boolean setting in AutoFilterManager - for example, CustomSaveRestoreGridFilter. If it is set to True, AutoFilterManager would raise 2 new events, CustomSaveGridFilter and CustomRestoreGridFilter, in which you could implement your custom save/restore grid filter operations.

Hi Igor,
yes, the idea could be to use the existing menu items "Save grid filter..."/"Restore grid filter..." to save to DB instead of file, opening a customised dialogue box:
.

The alternative would be to disable these entries and insert a couple of external buttons to achieve the save/restore functionality.

Either of your proposed solutions might be fine, I don't have a real preference, I would say to choose the one that is more in line with the general approach of the other grid features.

However, I want to emphasise that you have a great product, my team congratulates you.

Greetings

Maurizio

Thak you for your warm words regarding our product! We always try to listen to our customers and enhance the product with every release based on customer suggestions.

Adding custom buttons sounds interesting because they can be also used for other purposes. I would think about custom items in the Tools menu - ok? Because the current filter box layout is complex enough and placing command buttons on its surface may cause some problems.

And do we really need to disable the built-in Save/Restor grid filter functions? I think users may use them to save/restore grid filters locally for their personal needs regardless of your custom save/restore routines.

Two more question/thoughts:

1) Do you really need to incorporate commands that save/restore grid filter into the filter box UI? I do not see any problems with the existing Save/Restore to file commands. They can come in handy and can be used regardless of your custom filter processing commands that save/restore to the database.

2) Currently you can retrieve the filter criteria for one column with the iGColAutoFilter.FilterAsXmlString property. You can use it to create a compound string that represents the current grid filter to save it into the database. But I think that we could simplify this work if the iGAutoFilterManager class provided a similar FilterAsXmlString property that returns a filter string for the whole grid - the same or almost the save what is stored now to file with the iGAutoFilterManager.SaveFilterToFile() method. How about that?

And one more thing. If we decide to add custom items to the Tools menu, we may need an option to specify their position - before or after standard items - and a tag for every item to know what item has been clicked in the future ToolsMenuCustomItemClick event.

Hi Igor,
I think the standard Save/Restore commands can be left on, in case a user wants to save such a filter locally.
We will use the custom Save/Restore commands to save the filter centrally, with a flag indicating whether it is a global filter or a per-user filter.
Saving locally to a file could be thought of as a "private filter."

We are actually inspecting the filter structure to extract a "query tree" rather than a "query string." The reason is that we can translate it into a "query string" depending (mainly) on three usage scenarios:

1. simple query in which grid column names are also table column names
2. entity query in which the grid column names are entity property names
3. "web query" in which the grid column names are REST GET/POST parameter names

PS: custom items in the Tools menu sounds good!