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? ;-)

[kinook]

The search implementation does not give precedence of AND over OR, so you must indent to specify precedence.

An editable search field would also be unwieldy, considering all of the comparison and attribute options available in the grid.

[Spliff]

One year ago, I hadn't been aware of "Nested Searches" in UR, users should open the "Advanced Search.urd" example db (C:\Users\YourName\Documents\Ultra Recall Samples\Advanced Search.urd) and read the comments in "Nested Searches" in there, as well as the search examples they describe: Just as in real SQL code, UR searches permit to search upon the result sets of "inner" searches, the latter to be written first, then to be referenced within the "outer" ones, so just as AutoHotkey is a wrapper to Windows internals, UR searches, combined, work as a wrapper to real, sophisticated SQLite selects, so using UR's nested searches will also introduce more clarity in case than trying to force the above-described "grouping by indentation" search syntax (which can bring unexpected results in case, as mentioned above).

Also, whilst it becomes evident that these nested searches in UR allow for just quite fine "project management", whatever those "projects" may be, part of the comments there

("A difficulty I have run into is that I also like to keep emails and other files related to a task (GTD support material) stored with the related task. The most convenient way to do this is for the support material to be included as a child item of the task. This has the advantage that when I remove or relocate the task item the attached child files are removed as well (great for filing, etc.).")

remind me of the newly-introduced, SPECTACULAR "Tree - Show - Level ..." expand commands group, and it should also become evident that precise (instead of "chaotic") "leveling" is BIG help in "project management" of any kind, since - just a reminder, not a critique -, that will visually preserve the tree indentation(s), and the (real) contexts (i.e. not "contexts" as that term has been denaturated in GTD)... both which (even the best) search can't provide (and which, at the end of the day, is the reason why we use UR, instead of just a "flat" SQLite db).

(As said before, nested searches should conveniently be constructed bottom-up, and of course you could use (i.e. reference) the same "sub-search" within several more global searches, e.g. write a multiple "OR" sub-search just for multiple variants of calendar dates, within the items you want to retrieve or to exclude... which re-arises the problem of - currently missing - quick specific-data change within UR's searches whilst in real SQL(ite)) code, you would do by (regex-) search-n-replace, but that's another subject: perhaps, it would be possible to make available some input field for real selects, i.e. for the necessary code, and which would then only processed if it contained sheer search, i.e. without "updates", etc, in order to prevent accidental db destruction?)

Oh, and just by accident, I discovered a simple way to trigger any search: Select the search item in the tree, then press {tab} two times "in a row".