Any way to create a compound (flag) search preserving the tree structure? Or in tree?

[Spliff]

a) Within the TREE itself,

I can HIDE several flags, so that in the end, in theory, I have just a tree with the flags I want to appear. I can't hide regular (non-flagged) items though, so in order to realize what I need, I first have to assign a special, "regular" flag to all regular (non-flagged) items, then hide that "regular" flag, too.

It goes without saying that this comes with lots of side-effects, since your default item would now be a specially flagged item. Also, all this is entirely manual, since there are no STORED hide sets; a little menu with some 5, 6 (or even 12) entries for such sets would be welcome, with entry 1 = "everything is displayed", entry 2 = "hide flags 2, 4, 7", and the like.

This being said, it would be, or have been preferable to have such sets not in the form "hide flags x, y, z" but "SHOW flags x, y, z"...

BUT at the end of the day both versions would be practically the same IF the format "NO flag" (= regular = default item) could be INCLUDED in the flag list(s), be it for "show" or be it for "hide", in other words, in the (currently unique) flag list (currently for hide) it's the "NO flag" which is missing, so cannot be selected for hiding.

Adding this feature, "hide No-flags", within the unique hide-flags list, might be quite easy to implement? And, as said, some different such lists (sets), available by a menu, for different "views", would be welcome.


b) Within the SEARCH (compound searches, stored searches),

it currently seems impossible (?) to preserve the tree structure; several times in my 2 years with UR, I have tried, for hours, but I always hope I have overlocked the necessary "trick", or then, would it be possible to implement some system attribute giving access to tree preservation? (Of course, I ask for b) since current a) solution is so awkward, so if a) could be amended, b) would not be so important anymore, or then the other way round: if b) is / could be made possible, a) is not so important anymore.)

We now know that for a SIMPLE search, preservation of tree structure would be realized by sorting by lineage, then by tree order, e.g.
Item Title // Lineage (sort 1) // Tree Order (sort 2, means "child number") // other columns in case

This FAILS for compound searches, also when I try (perhaps mistakenly) with additional columns (IsObject, IndentLevel, or others):

Let's have a (stored) search for
FLAG = Red (for construction elements in different, higher-up indentation levels)
OR (which means "and" in the sense of "show items of either flag value")
FLAG = Green (for specific child/grandchild... elements for which I want to see the "distribution" within the structure)

Even in this really simple compound search the tree structure is NOT preserved: the "green" elements, by tree being direct or indirect children or grandchildren, etc of the "red" elements, do NOT appear "in place", even when there is NO missing = filtered-out element in-between, in other words, even if the green element is a direct child of a red element, it's not displayed directly beneath its parent but elsewhere = further down, and similar for the "construction" = red elements, which seem to be sorted by indentation level in-between themselves, and even some green elements appear in-between them IF their indentation level is high enough to appear in this upper part of the result list.


Of course, the b) SEARCH solution is of high interest here since they can be stored = be easily accessed then, and filtering out even regular (non-flagged) elements is a no-brainer here, whilst the (in theory, ideal) a) TREE solution (where filtering preserves the tree) currently has no such "stored" procedures (filter presets), and presents the additional "fail" of regular (default) elements not being filtered out even when necessary (interesting though, the filter code within the tree functions the way I would have expected it to work in search, too). But there hopefully might also be a current UR search solution, adapted to UR's specific search code internals?


EDIT

This might all be a big misunderstanding, since even a single flag search does NOT preserve the tree structure, with
ItemTitle, Lineage (sort 1), TreeOrder (sort 2)
listing all shorter lineages before longer lineages (i.e. ordering by indentation level even when that column is not even selected from within the "Choose columns" dialog; for finding elements (records), I might have not discovered it before, just assuming
ItemTitle, Lineage (sort 1), TreeOrder (sort 2)
displayed the search results in tree order (meaning: preserving the tree order from the data explorer), but for my needed filtering tasks, the fact that the structure of the tree is in part scrambled becomes obvious to the point of the result display not being of any use (the above described combination red-green becomes somewhat "better" visually (since then red and green are so much interwoven that you could think at first sight that it's all in tree order, but it's not, not at all) if I sort by TreeOrder (which in fact is "SiblingsNumber") first, then by Lineage, but it's just scrambled otherwise). Is there something wrong with my UR installation?

I am perfectly aware that for SIMPLE searches, the above does not correspond to what had been said in
https://www.kinook.com/Forum/showthread.php?t=5758
which shows that for me it's been a problem for more than 2 years now, and in
https://www.kinook.com/Forum/showthread.php?t=5462
which shows that it had been a problem for others even before.

So after 5758, we all thought that the problem, for SIMPLE searches, had been resolved. For COMPOUND searches, though, I then had thought this was a new problem, not having been treated before, whilst I now discover, on my system, that even for simple searches, the problem persists (btw, ALL ordering always in the way that the triangle shows UP (which means ABC), not down (which would mean ZYX)):

simple search for red flag, sort first by lineage, secondarily by "treeorder" (numbers 1 and 2 clearly visible, so I don't just assume but see on screen).

Real Tree Order (with indent levels):
0 (1) (first level below source-item)
p (2)
c (3)
z (3)
m (3)
y (3)
1 (2)
2 (2)
3 (2)
4 (2)
x (2)

Search result:
0 (1)
p (2)
1 (2)
2 (2)
3 (2)
4 (2)
x (2)
c (3)
z (3)
m (3)
y (3)

(For compound searches then, the (faulty) search results are as expected from the above simple-search results, but I now think that if the problem is solved, for simple searches, the compound search will produce flawless results, too.)

My data above representing (sic!) real data, i.e. longer strings, but with, in the real (!) tree, any greater indentation number (all 2's after the 1, all 3's after the 2) being a real child of the preceding lesser number (the 1 above them; the 2 above them), meaning the respective substrings before the respective "/" in the real lineage strings are identical, in other words, I just shortened the real data, but the example comes from real, real-world data.