Upper Limit (Category/Folder Tree Filter)?

[Darius1968]

I haven't tested this in the Media & Folders view, but in the Category view, I'm concerned with the Filter Tab that allows for the category tree to be either searched or filtered.  I apply a filter with the option of Regular Expressions.  At first glance, all seems well, but if I have many search terms (I simply separate the terms with the pipe "|"symbol) then this scenario seems to break the search engine, meaning that either the last couple/few terms will be dropped from the search, or results will be returned that have nothing to do with what I originally specified in the search.
Can others reading this verify this behavior? 

[Mario]

Insufficient info.
You did not even include your regular expression. The | symbol is usually used to implement alternatives and is usually not something you need just to filter out a few categories.

[Darius1968]

The alternative sets are exactly what I'm looking for!  Let's say that I want to filter my category tree hierarchy for these six objects of transportation:  car, auto, automobile, vehicle, train, airplane.  I came up with this regular expression: 
car$|(auto$|automobile)|vehicle|train$|airplane
I know that my category tree has entries for a six, however, the said expression is only considering the 1st five terms.  So, my question is:  Are others running into the same kind of a problem if they have an expression similar to mine, in terms of the length? 

[Mario]

I'm no regular expression expert. IMatch uses the PERL regular expression engine implemented by the Boost library.
Did you check your expression with one of the PERL regex compatible online tools?
For me it looks not right, not with repeating $ inside the expression alternative.
But as I said, I only work here. I don't use complex regexp myself and I hand over the regular expression to the Boost regexp engine, which is used by tens of thousands of applications out there.

[Darius1968]

I think the expression is right because if I break that expression up into two parts, testing each separately, both work as expected! 

[Mario]

Can't help you there, sorry.

[Carlo Didier]

I think the expression is right because if I break that expression up into two parts, testing each separately, both work as expected!

I checked it with RegexBuddy and indeed it seems correct.

[Darius1968]

I just need others on this board to test their category trees with many keywords that are separated by the pipe "|" symbol, to see if they run into the same problem that I do.  I think there may be a bug somewhere in this engine, and hopefully others can confirm the behavior I'm running into. 

[Arthur]

Cannot reproduce this, tested several or patterns, with $ and without. Tested also the given pattern replaced by my keywords. Everything looks OK.

@Darius The category filter filters only by category name, isn't it? So what is the category name, that should not match your expression and that is displayed anyway?

The only thing that I have obseved is, that the whole tree is displayed with a | at the end. But because an empty string is contained in every name, this seem to be OK.

[Darius1968]

Arthur, thanks for your efforts in trying to reproduce this idiosyncrasy.  You say that you tried to apply my same string, or another string, but with the same # of characters as mine.  This is important because as I said, a few search terms are okay, but it's when the size of the string gets to be this long (car$|(auto$|automobile)|vehicle|train$|airplane), that the last term, airplane is just omitted from the result, but I know that I have airplane in my tree.  Sometimes, the idiosyncrasy manifests as such that random & unpredictable chunks of the tree are displayed. 

[Arthur]

If this happens next time, please do the following:

1) Select the whole filter expression
2) Cut it to clipboard
3) Paste it to the filter text box again

If this repairs the resulted tree, then this looks like a timing problem, which occures with intermediate expressions while typing. My category tree is too small maybe.

[Darius1968]

I just tried your suggestion without any luck, but then again, I was never typing in this box to begin with, always pasted it in! 

[Arthur]

This were the important information you have forgotten to give. Could reproduce it now.

The filter box is limitted to a text length, which does not require text scrolling.
Try for example to type aaaaaaaaaaabbbbbbbbbcccccccccddddddddd and so on, it never scrolls.
The same is true for pasted text, it is just cut off at the last visible position. This has nothing todo with the pasted regex.
It is the limitation of the combox box control which is used for filtering.

What is also strange is that the default shortcuts like Ctrl+A, Ctrl+C, Ctrl+V, Ctrl+X do not work...

[Darius1968]

Interesting!  I've verified this now, for myself.  So, it's not a problem with the search engine, itself, as the problem is with the amount of data that can be passed on to it, via data entry in the search field that is limited in length by what can be seen, as scrolling beyond that point isn't possible!  I didn't point this out because it's not a quantity that I was on the look-out for, and hence, I didn't see or notice it. 

What I've also found:  One can't pin the limitation on how many characters are entered.  Different amounts of characters will fit in that text entry field, with respect to the actual characters (whose widths vary of and in themselves) entered at any given time. 

Any way to overcome this? 

[Arthur]

I think there should be a way to overcome this. Only Mario can tell.

If you try to enter a text in the "Folder Filter" of the "Media & Folders" tree, there the text begins to scroll. This is also true in the box which can be reached via Filter Panel -> File Name (based filtering).
It looks like the same UI control is used everywhere but with different limitations. The clipboard shortcuts for Select All, Cut, Copy, Paste also work in the Filter Panel text field. Maybe in the "Folder Filter", "Category Filter" and "Timeline FIlter" case the key events are consumed by some other UI element (like the File Window), so that the local filter text fields never receive the events and can not execute the clipboard commands.

Btw the scolling limitations exist also for the "Search" field in Categories Filter and Search/Filter fields in the Timeline Filter.

[Mario]

Just a missing option in the dialog resource. I have added that for the next release.
You were the first user since 2014 running running into this minor glitch.