|
Thank you very much for your question: In fact, I had left out the problems arising with the combination of the "Search for" field, and then the "list conditions".
Unfortunately, the string condition within the field has to be fulfilled by each result sine qua non, AND then the "list conditions" (lc) have to be fulfilled, as a block, either, i.e. the implicit code is:
(yourstring) AND (whatever your other conditions here),
in other words, there is a big AND between the "Search for" field, and the "list", and that's why, e.g., at the start of the very first "list" line (and different from any other list line), there is NO "and/or" toggle, since the whole list is considered "and".
I admit that for some compound searches, this (very limiting) construct is fine, but for others it's not, e.g. whenever you want, as I do, in my "simili hierarchy within a flat list" Advanced Search, have any (or, as here, even several) "list" conditions alternatively to your (main) string condition, not "above on" it, so, if I want to also display the "construction" items (i.e. the inter-titling, as in my example above), I have to type the search term as just another list element, the "Search for" field being useless = left blank.
In this context, it's also of interest to remind that a simple toggle "and/or" between the field and the list would not resolve the problem, since then again, the whole list would be considered as ONE (not additional anymore, but alternative) condition, and thus would now display too many results, instead of too few. (Since in my example, the "indent level" condition is additional to anything else, whilst the other list conditions are alternative to the string condition.)
That's why I had suggested an additional field "Individual", to contain, in case, the individual string (or perhaps number, in case, for address, or year fields, or similar: individual data vs. "schematic" data, within the other "list" fields) for any (but just one) list field which (by the drop-down list, so that would be easy to add to the drop-down) allows for either string or numeric input: Then, in order to have an input field, the last column in the "list" would mention "IND." or somewhat (selected, as said, by the respective drop-down entry), and IF there is just ONE such list field (for which the user has selected the "Individual" field content), the input of the "Individual" field above, between the "Search for" field and the "Start" button (or even just above the "Search titles only", etc. block of check boxes), UR would replace the "IND." marker by the content of the "Individual" field above;
- user chose "ind." for more than one list field > Error message asking for "just 1 such list field"
- user chose "ind." for one list field, but without content in the "Individual" field > (either error message, or, and preferably,) value / condition is excluded from the sql search string
- there is (previous) input in the "Individual" field, but no condition with "Ind." > "Individual" string is simply not included into the search, since there is no condition which would include it
This arises the question if the "Search for" field could probably be used instead, with adding the usual "and/or" toggle also to the very first "list" row; default being "and" (as usual, too), and the "and/or" would only apply to that very first "list" condition; you would remove the global parentheses around the "list block".
The problem with this alternative would be twofold: Error-prone on the user-side (as is the current "package" indentation within the list, instead of parentheses, indentation regularly indicating subordination, which is not the case here where it's just grouping); and then, the "Search for" field currently only allows for "search string everywhere within the items", neither "title only" nor numeric fields, in other words and e.g., it doesn't allow for "title:Search term to be searched just in titles", which would be a frequent (!) search, especially if users do tagging in titles, and it's obvious that almost every such "tag search" would be for different tags or different tag values, so this would be quite inferior.
In contrast, my problem solution above - needing an additional field - would both be much neater (i.e. less ambiguous) for the user, and would also allow for fast (!), individual, compound searches of specific title data, and of data within numeric, or then specific string fields, i.e. its application scope would be much broader.
(And at the end of the day, the introduction of an additional field would probably even become the very first step for some day allowing sql "select" strings, allowing for quick individualization of more than just one condition? ;-) (User-side AHK input box, then a macro writing the necessary select strings. Would happily share.)
|