Hi,

Sometimes the user needs a filter in an XTREE where it's not defined.
If it's urgent and I'm not in front of the computer to add it programatically, I can activate temporarily the OPTIONS=XTAUTOFILTER in the MIAME.ini.

The problem to activate autofiltering globally it's because, some columns were not prepared to receive it and the header becomes unreadable, also, in heavy xtrees, autofiltering can make them really heavy, almost unusable.
But, once activated, autofiltering can be turned off using the context menu "Toggle all filter buttons".

This said, what brought me here is to ask if it could be possible, and reasonable, to add autofiltering globally but not active by default, just adding the "Toggle all filter buttons".
That way, every XTREE will keep unchanged and with the possibility to use autofiltering.

Options:
a) If using OPTIONS=XTAUTOFILTER, maybe we could apply the inactive as initial state only for those XTREE w/o XTF2_AUTOFILTER explicitely defined
b) Use a different one, OPTIONS=XTAUTOFILTEROFF
c) XFLAGS2 = XTF2_AUTOFILTEROFF, to allow a specific XTREE to start with the filters inactive

Excellent observation / suggestion! In fact, I'm kind of embarrassed that the issue wasn't dealt with when the filter option was added to the context menu. Probably because the need for yet another option, with multiple ways to set it locally or globally, seemed just "too much" at the time.

It's a beautiful day here in Southern California (still muddy from all the rain, and cold by our standards, but sunny and clear) so I'm going out to get some fresh air and exercise, but will redirect some of that oxygen to the programming section of the brain to ponder it in background. I'm pretty sure we can come up with something to address the issue without it being the option-straw that broke the camel's back.

Well after a couple of days of sunshine and fresh air, I wasn't able to come up with anything better than your suggestions. In fact, I think the first one is probably the optimum, since it doesn't require any additional action on your part.

The main downside of enabling autofiltering globally (even when the header buttons are disabled) is that it does activate some additional logic and memory allocations just to lay the foundation for the possibility of activating a filter. I did some empirical testing which seemed to suggest (at least here) that the performance overhead of enabling autofiltering is about 10-15% as measured by the time to load and display the initial tree. For trees that display in a couple of seconds, that doesn't matter, but if you have a very large tree that takes, say, 15 seconds to load and display, it's another 2-3 seconds. The extra memory overhead is probably not significant in the grand scheme of things.

Ideally, we would be able to eliminate all of that extra overhead until such time as you actually applied a filter (or at least enabled the filter buttons). But I'm doubtful that will be practical because the filter capability changes the loading logic, making it difficult to initiate after the tree is already displayed.

So the main downside of globally enabling the autofilter would be that in some cases, very large trees where you never wanted to use filtering would take longer to load. We could deal with that by adding another flag at the individual tree level (like your 3rd suggestion), allowing you to eliminate all of the filter overhead in large trees where you weren't ever going to use that feature. (Another option, eliminating the need for a new flag, would be to recognize the Advanced Coldef Option Filter=None in the zero column as overriding the global OPTIONS=XTAUTOFILTER.)

But note that what we're talking about is whether the possibility of enabling the filter buttons is enabled, not whether the buttons are enabled. (Enabling the filter buttons doesn't involve any measurable overhead - it's the support for the possibility of filtering during the initial load that requires the additional overhead.) The main reason for hiding the filter buttons is aesthetic, i.e. they take up a lot of space in narrow columns.

Of course the real overhead occurs when you actually use the filtering mechanism. And that, unfortunately, is rather slow. It probably could be better optimized, but it's necessarily complex due to the aggravating need to work around the "natural" way of doing it (which is apparently protected by patent).

One other related refinement might be to add to the context menu an option to toggle the filter button for just the current column.

I'll tinker with all these ideas over the next few days, hopefully having some refinements to release.

Hi Jack,
I agree that activating anything globally will always bring up some exception that we didn't think about so, maybe we should focus on the approach that implies some adjustment on each XTREE.
This said, my proposal is to add the possibility to define the initial state for XTF2_AUTOFILTER maybe using something like FilterInitialState=Disabled in the zero column ?
In that state, the context menu should have the options for Filter but the columns filters are hidden.
As for the option to allow enabling a filter for a specific column, that sounds very nice because we could disable filters for columns particularly thin w/o completely loosing the filter option over those columns.

Thanks

Hi Jorge,
The plot thickens...

I was thinking of the scenario where the tree starts with no filter buttons and the user decides to filter on a specific column by right-clicking on it, choosing the "Toggle Filter Button for This Column" option, then clicks on the button and enters the filtering criteria. (Analogous to what one would do in Excel, except here we can't start by clicking on the column header without getting the side effect of sorting the column, so we have to treat the position of the right-click as optionally indicating the one column to be filtered.) In other words, enabling per-column filtering selectively/interactively.

You were thinking of doing the same thing from the application / individual-tree level. That makes more sense if you want to control the initial state of the filter buttons for each column, but still allow the user to activate filtering on the columns that didn't start with filter buttons. More flexibility, at the cost of more effort configuring the tree.

Both approaches have their benefits. For the application-level configuration, rather than create another Advanced Coldef Option (FilterInitialState), maybe we can just make it an optional suffix on the existing Filter option: Filter=<type>{,<initial state>}, for example:

Filter=CB,Disabled
Filter=PATTERN,Enabled
Filter=RANGE (default state is enabled)
Filter=NONE (initial state not relevant)
Filter=*,Disabled (valid only in zero column; sets the default state for subsequent column filters)

OR why not just add the ability to export your grids to excel and let the end user manipulate the data on their own while you add the necessary code?

I am categorically against "solutions in search of a problem" approach to problem solving. If tools already exist in the toolbox to provide a solution then it should be acceptable to tell the users that they need to wait for the appropriate coding to provide them with their request.

^^^ Case in point Jacks last post ^^^

Jack, probably I misunderstood your suggestion and add confusion to the project.
Let's try to reset my proposal and try a simple implementation.
What I want is to allow filtering in some xtrees but on demand, activating it via context menu.
To achieve that, I must set XTF2_AUTOFILTER but need an additional FilterInitialState for the whole xtree to define if it's active by default, or not.
With FilterInitialState=Disable, the xtree is created without the filters visible on each column and the Filter option available in the context menu.

So, there is no relation with this new FilterInitialState and the Filter setting to set the filter type for each column.

To not complicate things, let me know if this clarify and simplify.

Frank, completely agree and use, that's why all my xtrees have the Export to XLSX active, no one can complain about not being able to handle their data.

Thank you

Keeping it simple is both desirable and very difficult to achieve; the thought of trying always reminds me of the Mark Twain quote apologizing for writing a long letter because he didn't have time to write a short one.

It sounds like maybe there is no great desire for setting the initial filter state (button visibility) at the individual column level independent of the filter type. (I thought the main incentive for that was to deal with trees that have some very narrow columns that you might want to be able to filter on, but you don't necessarily want to obscure their titles by making all of the filter buttons visible at once.) But we can certainly defer the option of adding a second parameter (initial button visibility) on the Filter= Advanced Coldef Option.

Back to the original goal of allowing the possibility of letting the user activate the filter options without having to initially display the buttons, here's what we have so far with OPTIONS=XTAUTOFILTER and XTF2_AUTOFILTER:

• If XTF2_AUTOFILTER set (regardless of OPTIONS=XTAUTOFILTER), then filter buttons are initially enabled (visible) and can be toggled off via the context menu
• If XTF2_AUTOFILTER not set but OPTIONS=XTAUTOFILTER is set, then initial filter state disabled (buttons not visible) but can be enabled via the context menu (implemented but not yet released)
• If neither XTF2_AUTOFILTER or OPTIONS=XTAUTOFILTER are set, then filtering is disabled and can not be enabled by user.

Regardless of the above options, filters can also be disabled (without user option to enable) by setting Filter=NONE either for individual columns, or for the zero column.

The one shortcoming of the above options is that you can't explicitly request the 2nd scenario (filtering available but initially disabled) without depending on the global OPTIONS=XTAUTOFILTER being set. So if we add the InitialFilterState option, you can use that in combination with XTF2_AUTOFILTER to have total control at the tree level. That seems reasonable to me.

Do we want to have a context menu option to toggle just the current column's filter button? (It's basically ready to go, but if it's not useful, it's easy to comment out.)

One happy side effect of all this thrashing about with filter options is that I may have figured out how to drastically improve the filtering speed.

In a quick reply, because Violeta is waiting for the hot milk with chocolate, the implemented scenario completely satisfy my needs.
Toggle just the current column? Yes please, that was a great idea that you introduced here.
The best of all is the drastic improve, I'm happy with just that, many thanks.

Now it's time to continue the story telling of the brave girl fighting the giants in the forest :-)

Just so as to not leave the brave girl or the giants in the forest hanging, here are the updated modules and footnotes to the story...

ash65notes.txt
ash-6.5.1724.1-w32-upd.zip
ash-6.5.1724.1-w32c-upd.zip

Hi Jack,
The new option to set XTAUTOFILTER active by demand for all xtrees together with the "Toggle filter button for this column" was precious right now while debugging a problem in a customer.
Without it I would take a lot more to find the issue, adding the filter XTF2_AUTOFILTER that will remain there and probably confusing the users with the crowded header.
Just perfect and useful.

I've noticed one detail that maybe needs a look.
Activated the filter button for one column using the "Toggle filter button for this column" and worked perfectly but, after applying a filter to the column all the columns got their filter buttons active.
In my case it was even better because I need a second filter in another column but it's not expected besides harmless.

thank you very much

Thanks for the feedback. I have to admit that I noticed that particular quirk, but while trying to decide whether it was a feature or a bug, got distracted and forgot about it. Technically it should probably be considered a bug, but the downside (possibly obscuring the text in some narrow column headers) and the upside (anticipating your likely next move, i.e. to filter on another column), are roughly in balance with each other. So I think I'm going to put it in the "to sleep on" category for now.

Definitely that's a wise decision which I aprove