Advanced Search with tree preservation (sort of) - HINT

[Spliff]

As I said some months before, I absolutely need Filtering in correct tree-order, and since Tree-Filtering just applies to flags, I also need some filtering by Search, for other item attributes.

Thus, in view of the problems we discussed, with "Search - Sort by Lineage, then by Tree Order" - here, the longer paths are not interwoven with the shorter ones, but placed behind the shorter ones, so tree order is not respected -, and since I need tree order preservation absolutely, I took out sub-trees to new UR DBs (so this augments the number of my UR DBs even more), then "flattened out" the hierarchy in that sense that in fact, I "flattened IN" the level 2 "core items" INTO the range of the level 1 "section" titles, preserving somewhat visual "hierarchy" with separator lines plus bolding (understood that only the "titles" are black-bolded, other items being only colored / italicised in case, but never bolded), i.e. previously:

0 - source item
1 - title
_2 - some item
__3 - some subitem(s) here
_2 - another item (any formatting)
1 - another title
_2 - some item
etc

now instead:

0 - source item
1 - title
1 - some item
_2 - some subitem(s) here
1 - another item (any formatting EXCEPT bold)
______________________________ (separator line (otherwise empty item))
1 - another title
1 - some item
etc
______________________________
1 - another title
1 - some item
etc
etc
______________________________ (bold line here, not replicated by the forum software)
Templates
Recycle Bin
INBOX
etc.

(Understood that you can further strenghten that (purely visual, not also technical) "hierarchy" by putting some "section titles" into CAPITALS, and / or can bolden (or not) the separator lines, as well as use shorter and longer separator lines (e.g. 20 underlines "_", or then 40 instead.)

NOW, since the "titles" are "bolded", i.e. they bear a specific flag, you can systematically search for them, in order to see the structure, AND you can search for your real target items, viewing the results, correctly "situated" within that "tree" structure, even with separator lines if you want, e.g.

Section 1 (some title)
item with "hit"
another "hit" item
____________________
Section 2 (some title, NO "hit" in here)
____________________
Section 3 (some title)
3 "hit" items here
...
...
____________________
Section 4 (some title)
etc
etc

Now, all this is in perfect "tree" order (since technically, it's not a tree but a flat list), but of course, this only works this neatly* as long as you only search for results within this flat list, i.e. within the "core" items which, to this effect, have been "promoted" to (the original "title" level,) level 1.

(*= whilst also including search results "deeper down" would ask for another search code, and then those results from "deeper down" would not be included in the (simili-) "tree" schema above, but listed below that, i.e. without any "location" indicator)

Now, for the above to work, you'd write an Advanced Search as follows:

Item - contains keywords - YourSearchTermHere
or Flag - equals - Yellow (or your respective "Bold" flag)
or Item Title - matches wildcard - _*
____and Indent Level - equals - 1 (you indent this "and" condition)

or you do it the other way round, indenting 3 of the 4 conditions:

Indent Level - equals - 1
____and Item - contains keywords - YourSearchTermHere
____or Flag - equals - Yellow (or your respective "Bold" flag)
____or Item Title - matches wildcard - _*


and finally, if you want to see ALL occurrences of your search term, of which at least the "core" item "hits" within the "tree" structure, the "rest" below:

Item - contains keywords - YourSearchTermHere
____or Indent Level - equals - 1
____or Flag - equals - Yellow (or your respective "Bold" flag)
____or Item Title - matches wildcard - _*


You see here ( i.e. in this blatant example of "shaping your work to the software", instead of it being the other way round ;-( ) that the (very first of several ones, in case) "contains keywords: ..." condition (and independently of it being for Item or Item Title, or possibly even another attribute / column) within the Advanced Search (AS) , should be available by some additional input field (and which is then accessible by Tab and, in particular, macro-accessible by its own control name, e.g. "Edit11" or similar), the respective value within the AS "list" then NOT being your specific search term anymore, but "[entry]" or similar: Since again and again, users need the same stored searches, but with an individual (i.e. ever changing) search terms, and fiddling with the value within the "Value" field in the "list" here is very time consuming, and copying your 10 or 12 most frequent search terms into 10 or 12 otherwise identical copies of the same search schema doesn't help but to some degree, beyond causing lots of unnecessary clutter. ;-)


EDIT:

I only mentioned it above ( referring to https://www.kinook.com/Forum/showthr...hlight=lineage ), but of course, that's the way it's to be done: for tree results, select any columns, but incl. Lineage (sort by: click the header) and Tree Order (sort by, secondary: control-click the header); and, of course (but with much less "clarity"), you could preserve that special "tree" within your original UR db (instead of creating a new one for it as I did), then adding a condition "Lineage must contain ..." (and adjusting the indentation level condition of course); this would also work for several such special "trees" per db, but I want it "neat", so I created additional DBs instead.

And, of course, making available QUICK entering of the MAIN STRING CONDITION, within ANY Advanced Search (= stored compound search SCHEMA, but for INDIVIDUAL main strings = search terms), would be a tremendous step ahead indeed:

Then, HOW to do it technically? Above, I mentioned the "first currence" of the condition, "contains keywords": this would be weird both for "the developer", Kyle, AND the user (for construction of their respective search schema). Much easier for both:

Allow, within any STRING value field in the list (wherever it is within the search construct), a special entry, e.g. [§§§] or similar (fixed by the UR code, then to be entered by the user exactly like that), and write the necessary code (easy) which "links" that special entry to the current content of the "variable string" field (above the "list"); and (also easy) don't do trigger the Search but an error message whenever the user has put in that "special string" in MORE than just one string value (or any other) "list" field; alternatively, add an entry "Individual value" to the drop-down in the "list" (by "list" I mean the "click-together" part of the AS) wherever a string (or number) entry is allowed (i.e. whenever the drop-down contains an entry "contains key word", or similar for a numeric value); then again, if the user has chosen that "Individual value" more than just once in their "list", upon "Search", instead of triggering the search, trigger the message "Just one value as "Individual" allowed. Please rectify".

That way, the code remains neat, AND the user can start to regularly use stored AS schemata for their individual, always changing search strings! ;-)