Advanced Search with tree preservation (sort of) - HINT

[cnewtonne]

Here it is. Took me few minutes to find it

[Spliff]

Thank you very much!

I had NOT found it, since I hadn't understood your, "Drag to expand beyond the last column header to show it.": drag WHAT (transitive verb > object needed?), and from WHERE? - and my eyes are not good enough anymore in order to distinguish 2 pixels from 1 pixel.

I made a screenshot then, and the screenshot finally showed it was 2 bars in parallel, not just one, so I finally could drag the second bar to the right... pfff! (So I spare you the screenshot) ;-)

[Spliff]

The AS GRID again.

As said, Tree ("Data Explorer") filtering is worth only so much, since can't be done but by the respective flag of the items, and any item can't bear but 0 or 1 flag, not several ones - which is logical, of course.

So I filter by Search Results pane, and work (sic - working on data, in opposite to info gathering) from there, and, as explained, I limit my "Core info" to level 2, put the intertitles into level 1, but replicate those titles in level 2, as very first child item:

root (level 0)
1 (level 1, titles numbered for sorting)
__2 - title 1 again, bolded and as full-title i.e. with meaningful denomination (level 2, remains child 1)
__ some item (level 2 child 2)
__some item (level 2 child 3) ETC ETC
2 (second level1-title)
__2 - that title replicated for level 2 and with full-text-title (stays on child position 1) (bolded)
__some item (level 2)
ETC

Then, as also explained, it's possible to search for any info, within level 2 only, AND to have the intertitling also present within the search results; for this, it's necessary to use AS (i.e. QS is not sufficient); see the screenshot; the name of the search lists the columns to be displayed, and their respective sort order/precedence.

As said above, an organic way to do such a search would be:
Search for: xyz

then the AS grid:
line 1: OR Notes contain °t (or "Flag is bold"): this for the intertitling
line 2 (indented!): AND Level is 2
> SQL: (xyz or Notes °t) AND level 2

Thus, the "Search for" input-field would be considered as the very first (and non-indented) row of the grid, so that the current grid row 1 would also get and/or, which would affect its relationship with the "Search for" row.

This would made possible to trigger stored searches, put the (variable, main) string value into the "Search for" field (which already has focus), then enter "Return", and the AS is done.


Contrary to the above, UR's AS grid works this, totally unnatural way:
The "Search for" string is one "AND" part, and the whole grid below it is the other "AND" part of the search:
(Search for string) AND (The total outcome of the Grid)

And thus, in order to put in the string, if that string is not by an additional AND condition, but by an additional OR condition (in one, or as block, the grid is always AND, to "Search for", currently!), the user has to type about 5 times "Tab", in order to get into the grid, then has to navigate, in several steps, to the string value field... whilst the "Search for" field (where the string could have been entered with minimal effort and in a fraction of the time) remains empty: this is aberrant indeed!


Just some days ago, some alleged "review" has been written here, https://www.outlinersoftware.com/top...-8--new-review , and again, it's said that UR (to which MI is compared for several aspects) was "slow" in comparison...

which obviously is not true BUT the user-software interaction in UR would "MAKE" it "slow", in that sense that this interaction takes much to many steps, for regular, frequent actions which should become easy, "smooth".

In this respect, also in that "review", UR's attributes system is mentioned, and compared to MI's (which has some of that mythical "Ecco" grid (but which does NOT make it possible to enter values into those fields programmatically, but only by selecting the field by mouse-click first (!), and such "reviews" systematically shovel such relevant detail under the carpet...

But fact is - and we discussed this in another thread here, some time ago -, when I want to use a (factory, or user) UR "attribute" for tags or other values, adding / setting / updating that "attribute" is far from easy, since I first have to display the attributes pane, then have to to navigate, deep into the attributes list in there, and that "takes time": too much time indeed, and thus, people say (without ever specifying though), "UR isn't fast enough".

Btw, that's why I now display a 1-line (!) Notes pane, and put my tags into that Notes pane, living with the fact that then sorting (!) by the Notes pane makes sense only for the very first tag in that pane, and thus, for other tags in there, I just can search of course, obviously, and from my experience, that's ok with me: I always put the tag by which I want to sort, as the very first one.

It's the little things that are awkward, e.g. I had to use the Notes pane as "tags pane", since my original idea to use the very first line of the Content pane (i.e. the "Item Text"), then put a blank line after the tags, then start my "regular text", will result in the UR code deleting (!) the blank line, i.e. the two `r`n, ditto for tabs, and so, and put the following text directly after my tags; in order to avoid that, I would have to make a "blank" line, containing 40 or more spaces, in-between my tag line (line 1) and my text begin (line 3), so I chose the Notes pane solution instead.

(As for leading (!) dots and commas to be considered "is a word character", and thus becoming usable as a "tag code" (.tag instead of °tag e.g., for quicker entry and more pleasant visuals), I'm not sure of the coding implications for avoiding problems with trailing . and , as trailing chars, re fts, but, as said there, in MI they are allowed as leading string chars, and correctly filtered by (in the tree, as said).)


Please look into the "'Search for' as part (!) of the AS grid, instead of the grid being a forced additional (="AND") condition for the 'Search for' string" problem: Prove people wrong when they say, "UR is (too) slow"!

.

[kinook]

Modified to allow combining quick and advanced search with or condition in v6.3.0.17.

[Spliff]

There are some QS/AS designs, (a), (b), and (c) (see above, and below). For my task(s) at hand, I had found some (working!) solution for design (a), and came here this Sunday morning to share it, AND for explaining why my suggestion of a design (b) wasn't worth much, and why my suggestion for design (c) was much better indeed.

I then discovered your new design, which visually would be my design (c), so had high hopes (in spite of these hopes being turned down a little bit by your (as always, extremely concise wording)... and yes, technically, your design is (b), not (c), and yes, I cling to my solution for the time being, since design (b) (albeit looking as it was (c) then), at the end of the day, doesn't help me in any way for my current problems... but then, as said, I came a little bit late with my (necessarily theoretical) findings - now (unfortunately) being backed up by my (logically expectedly, useless) tries with v. ...17.

Thus, I can't hide my personal deception, for my means, but let's hope that for some of third parties' needs at least, (b) (in (c) appearance, hoho!) will be of real use then; I very much appreciate your effort though, and yes, I hadn't "seen" in time, had been aware of the superiority of (c), but not yet of its weight of importance for my problem, and probably most such problems, except for the very last days... ;-(


In what follows, YOU is the user, STRING is the string in the "Search for:" input box, GRID is the grid, in case as the grid-condition as a whole:

Above, I had presented two designs, one declared as better, one as lesser:

a) The then current, i.e. the previous one (i.e. before v17):
String
AND (implied/mandatory)
Grid

b) The "lesser" one:
String
AND/OR (= a toggle button in-between, AND being the default value)
Grid

c) The (in fact, much) "better" one:
String (logically as Grid's "row 0") (whenever there's a grid; else it's a stored QS)
AND/OR Grid row 1 (AND being the toggle's default) (technically grid row 1, logically grid's second one)
AND/OR more Grid rows (as always)

Now you have implemented (b), but with the appearance of (c) - which doesn't make it (c), obviously.


Now:

Logical (inclusive) OR (i.e. not exclusive XOR, of which we don't speak here) means, practically, MORE, tendentially (or=more, that's easy to remember), whilst logical AND, in practice, means LESS, and this paradox-on-first-sight resolves easily when we recall that both, AND and OR, apply to the conditions, not to the results, and more conditions, by AND, logically tend to shorten the result set, since more conditions are imposed on the "original" set.

(In what follows, let's also remember that String can be a construct of single string, and/or string and/or string... to a certain degree at least, I haven't tried this out thoroughly, and, as already said, with AND having precedence over OR (as in the abc).)

Let's assume that all "wanted" String strings are on level 2, and that you also have put the intertitling on level 2 (flag yellow=B=Bold; alternatively, you could have "marked" those Titles with a tag °t for example; in the end - we'll see this below, this tag = string solution for the Titles is even the only neat one, i.e. if you don't want to have "surplus", unwanted String "finds" - we'll come to that later)


Now, in (a) which was "(String) AND (Grid)":
String: xyz
AND (mandatory)
Grid: IndentLevel=2 (that's a valid condition since only xyz on level 2 are wanted)
> you get all xyz-items on level 2 but not the Titles ( as expected, so you add: )
OR Flag = yellow/Bold
> you will NOT get more results here (i.e. the bolded Titles) since OR is just another condition for the xyz items (which doesn't make sense (sic!), but since it's OR, it will at least not cut in your xyz results either); thus you add:
AND Flag=b
> cuts into your xyz results, i.e. will only show any bolded xyz items (whilst you wanted additional results instead, and anyway, you don't bold any of your "regular" items (but format important ones otherwise), since you don't want them to be visually mixed up with the Titles (which, necessarily = in order to maintain the tree order within the search, are within the same level 2 as their (conceptual, but not also technical) "child" items)


BUT what you CAN then (always in (a), or even now in (b), whilst NOT (being able of) taking advantage of (b)'s first-grid-row' AND/OR toggle):
Not only bold the intertitling (for your eyes only, haha), but also add a °t (technically needed now), to their title, or to their text, or wherever (or some other, similar STRING tag, obviously) and then:

Columns/Sort: Title0, ParentTitle2, TreeOrder3, IndentLevel1
String: xyz OR °t (the " OR °t" part by control-Enter in String)
Grid: AND IndentLevel = 2
> perfect result and thus my chosen solution, possible both in previous (a) and current (b), if, like me, you want all xyz items of level 2, together with their intertitling (and nothing else, e.g. xyz-items of levels>2 (since we have found that it's impossible to also sort these into the existing tree structure))


If you try, in (b) now (i.e. with the leading OR made possible), to "hold neat" the String, you will have to live with unwanted finds BUT which are BELOW the wanted ones, so that's technically possible, too, just a question of your preference, you either have neat search results, from my solution before, or you have a neat search string, as follows (Columns/Sort as before):

String: xyz
Grid: OR Flag=b
> again, you get the wanted results (i.e. the level-2-xyz with their intertitling, and we see here it's a real OR indeed, not a XOR), but below those, all other-level xyz finds (always given that level 1 is just there in your db for the (necessary) "ParentTitle" sort and doesn't contain any xyz-strings/items, obviously)
AND IndentLevel=2
> as without the AND since the AND (=the indent level) is just another condition for the Flag, NOT also for String (xyz, and which is what you will have wanted though), so, here again: 2-level-xyz's and Titles correctly ordered, then all level>2-xyz-items

Now you can fiddle around with these, String always xyz, then:
Grid: OR Flag=b
__AND (indented) Indent Level=2
> same as before (i.e. first what you want, then the unwanted level>2 xyz finds)

ditto for Grid OR and AND both indented,

whilst Grid:

AND IndentLevel=2
__OR Flag=b

and

__OR Flag = b
AND IndentLevel=2

> both show only the level-2 xyz items but no intertitling (and thus, it would not make sense to then fiddle around with the sort-order):


Since again, what looks like (c), is (b) in reality, so there is no way to add, in the Grid (sic!), BOTH
1) any additional condition(s) for the String, AND
2) any alternative condition(s) for the search but NOT also affecting the String condition,
at the same time:
it's either 1), with the first Grid row starting with AND,
or 2), with the first Grid row starting with OR:

No way out of this in current technical (b), and whatever you try: "It's the logic, stupid ;-)", in order to dare fudge Marilyn Monroe, or in other words, if you need a "mix", try to replace some non-String conditions by additional, "or", String conditions in case, so that the Grid can then either work independently of those (OR) or affect ALL of the String conditions at the same time (AND, might be quite rare...).

Hence:

Whilst previous (a) gave the only possibility to add additional String conditions via the Grid, current (b) also makes possible to add alternative conditions to the String condition (by first Grid row OR instead of it being the default AND), but not (yet) (as (c) would have done) the possibility to MIX alternative conditions AND additional String conditions.

Such a mix IS possible, obviously, if you leave the String empty, and put all necessary strings into the Grid (or with design (c), obviously, for global strings).


And here's the necessary code to smoothen / speed up such searches in (a) and (b): you just enter your "original" string (here xyz) and press Enter (you would need to have Tools-Options-Misc. - "Display selected item title in window title bar" ON, obviously):

$enter::
if winactive("ahk_exe UltraRecall.exe")
{
if winactive("distinct name of your stored search here")
{
controlgetfocus, s
if ( s == "Edit2" )
{
send, {end}
sleep, 100 ; ms
send, % " OR °t" ; or whatever additional global STRING condition(s)
; you need the % for the "", and you need the "" for the leading space
sleep, 100
send, {enter}
}
else
send, {enter}
}
; else if winactive("distinct name of another stored search here")
; as before, etc, then finally:
else ; any other Enter press in UR
send, {enter}
}
; else if winactive("some other application")
; ... etc
else ; for any app not listed before
send, {enter}
return


EDIT:
A "typo" above (any ":" and then ")" without a space in-between translate to some smiley), and just for completeness:
Possible "tag codes" (among more or less "readily available special chars) in MI do not include period and comma (.,) but are restricted to § and _ (e.g. §some or _some), whilst, as said, such characters in UR comprise the four chars ¬, ¦, § and ° (as used above).
And the recently added "Exclude" checkbox also helps enormously with constructing correct grids ;-)