Unexpected compound search results (with hints)

[Spliff]

First an aside: 7 flags, plus 1 no-flag, makes just 4, not 7 user-definable tree formats, when that user needs their formats in "regular vs. bold", e.g. black regular/bold, red regular/bold, green regular/bold, and violet regular/bold, and then, "underlined" or "italics" as other format variants, just "forget'em", so 7 flags are just not enough, and my work is severely handicapped by this....

Now for the compound (advanced multi-search-elements) search; its explanations are spread over multiple help items, not always inter-linked.

But I understand you took the real, Boolean, SQLite search string, put the elements into distinct lines, put the parentheses into distinct indentation levels, and within (!) those groups (originally within parentheses), the respective first (!) line's AND or OR is to be understand as AND or OR BEFORE that group; problems arise though whenever there is a mix of ANDs and ORs within (!) such a group, since it seems that AND then has precedence over OR (i.e. implicates a parenthesis within the group), but there are obvious faults in this (!).

Searches can be stored, but Del does not just delete the value, but the whole line, and Reset does not empty all current values, but kills all the lines of the (even stored!) search! (And a possible "locking" will even prevent the user from changing those search values.)

The above already implies that in order to have multiple searches, with each of them multiple possible search values in all or at least some of the lines, I will have to write and store multiple searches, then an external macro then hampering with the necessary changes to the values; this has been successful but takes some time, "from the outside", all the more so since I have to send mouse clicks, too, since it's all just "SftTreeControl754", and only after selecting plus activating (!) each value field, it becomes, invariably, "Edit3". So I installed a very first search line "Item Title exists" (since that exists for every item), have my macro click into its "value field", where it then just activates it, and then I can use {downarrow}, in order to change the values of the "real" fields...

So all this works indeed, but every such search takes even some time to enter, before the search can start...

I would greatly appreciate an additional, editable (!) "search field" (visible / hidden by some toggle of course, in order to not bother "basic" UR users, and) which would just display the "result" of all those search elements clicked-together in multiple lines, and which, by being editable, would also allow for just entering the final search command as-is (and since it's just search, not search-n-replace, it's obvious that even possible errors in that would not cause any harm to the db).

This one-line search field for advanced search would then be available without the "search for" pane, but just within the space for the menu and the toolbars...

Now, any UR user is well-advised to create some simple, dummy (!) UR db, in order to CHECK if their multi-line advanced searches bring the wanted results, i.e. all of them, and only them; for a (very basic) start, I created an UR db with just 10 text items, just titled 0...9. On that, I then run the frame (skeleton) of my real searches, in the form 1 and 2 or 3, etc., etc., with or with group indentation, checking if I get the expected results.

1
and 2
and 3
gives the expected result, i.e. none here, and similar with OR ditto, i.e. all three then; as said before though, combinations are problematic:

According to the above, AND having precedence over OR,

1
and 2
or 3,
read as, i.e. translated to,
(1 and 2) OR 3,
gives, as a result, 3, which is correct, but

1
or 2
and 3,
would, according to the above, be read
1 OR (2 AND 3)
and thus sould show the result "1",

BUT shows "2" as a result, which is faulty in any case, since, with precedential OR, i.e. read as
(1 OR 2) AND 3,
it should show no results instead; as said, item 1 only (!) contains "1", item 2 only (!) contains "2", and so on...

And that seems to be a systematic bug for OR before AND within the same group, since
1
or 2
or 3
and 4
i.e. to be read
1 OR 2 OR (3 AND 4)
(AND has precedence) should result in 1, 2, or, to be read
(1 OR 2 OR 3) AND 4
(OR has precedence) should result in NO result, since, as said, none of the 1, 2, 3 also has "4" in it;
instead, it results, in 2, 3, i.e. gives items 2 and 3 as alleged results.

On the other hand, search frames like
1
__and 2
__or 3
____and 4
____or 5
work fine, i.e. give the correct results for real data;

also, first OR, then AND, if (!) the OR then is in its own (here: even single-line "group", separating the other group members from each other (!)), work correctly:

1
__or 2
and 3
or 4,
to be read (i.e. with AND having precedence within (!) the group but not beyond) as
((1 AND 3) OR 4) OR 2
gives, correct, 2 and 4.

From the above, and especially from the last example, it becomes perfectly evident that your decision to do away with parentheses, and try to replace them by indentation levels, complicates things, instead of facilitating them,

both for the user, and for your re-transcription code into the real search string.

Also, the question arises, re fellow UR users, why is it that I discover such things the very first hour (!) I try some function(ality new for me), whilst some UR users allegedly will have used such faulty searches for years, without checking, and noticing? Or then, did some not even care to share their findings? ;-)