|
A)
I hope my previous post is understandable, though, when detailing the problems which arise with navigation in level hierarchy (equivalent to the file system's folder hierarchy, and in which the user doesn't encounter those problems, so that in order to do RELIABLE navigation (which is even more important for moving / copying items), a flattened (or you might call it virtual) hierarchy is preferable.
Btw and inadvertently, I had left out the main argument for that flattened hierarchy (construct b instead of construct a):
Construct a)
'a (all these expanded currently, or even just to be expanded by navi-macro)
__.a
____be it some item here
__.b (the .marker assures you get here, instead of the "b" item before)*
__.d (they can be grouped by subject, no abc-sorting needed)
__etc
''b
__.a
__.c
Now, the user wants to "go" to 'a .d:
> (s)he will enter ad, the macro does rest, and (s)he gets to the .b "in" 'a
> perfect
(And you wanted to go to the "b..." item, you entered aab instead, the macro navigating to 'a..., then to .a..., then to b...)
But the user is mistaken, wants to go to 'a... .d... in fact, but thinks that .d... starts with c ((s)he will have named the .d... by some synonym .c... but fails to remember):
> enters ac, expects to get to 'a .c (but that doesn't exist)
> boom: will arrive at 'b .c instead: Not too much harm for simple navigation, but really awful for moves! (Given the fact that all such navigation is done by character entry within the Data Explorer.)
Now the same situations in construct b):
.a
.aa
__be it some item here
.ab
.ad
.aetc
.b
.ba
.bc
You enter a, the macro goes to .a; you enter ab, the macro goes to .ab; you enter aab, the macro goes to .aa, then to the b-item (child of .aa).
But now, if the user is mistaken, thinks .ad is called .ac, (s)he enters ac or acsomething in order to get even deeper into .ac - and (s)he will NOT "land" somewhere in .b but in .a (since .ac doesn't exist): You "land" (or move something as last item into) the parent range, where you (or the moved item(s) will be much more "at home" than you, or they, will be somewhere within .b.
In the file system, that's no problem, since any path element's (=intermediate folder's) existence will be checked, and there is does not exist, the macro stops, and goes to (or puts into) the nearest parent folder (which does exist): These verifications cost just some ms in the file system, but would cost a multiple of that within a db (here UR), since then they would imply the (even repeated, in case!) use of the clipboard (or repeated sql accesses from the outside, and clipboard access to then process the results: a nightmare for the user!)
And that's why in a db where the user can't access the internals but from the outside - respective internal code would be much more elegant indeed -, construct b is much more preferable: quick navi / moves much less prone to annoying mistakes.
B)
As for the awful placement of the (very valuable otherwise!) AS Grid "Exclude" column, there is sub-key in Ultra Recall/Settings/SearchGrid, (i.e. not in the sub-key "Options"), "Order", with default value 0,1,2,3,4,5, so I have now tried to change that order to what I had intended, by changing the sub-key's value to 5,0,1,2,3,4, then rebooting, but that change does NOT work as hoped by me, the Exclude column remains last one in the grid, and the value has automatically (!) be reset to 0,1,2,3,4,5 - expected behavior? (Or should that have worked as I had hoped?) Would it some negligeable effort to put the Exclude column as first instead? (see above)
C)
Kyle, I'm very pleased you're looking into these problems, and it seems they are even more profound than you have already discovered, there will be some more glitches to be culled! ;-)
From what you have already found, it seems to me that my OR/AND problem started with 6.2 then (but without me making the connection since at the time, I hadn't already been in so fierce need for OR (and, to a lesser degree, the rest: ?/[])).
I had quickly reverted, at the time, to SearchNonAsciiTextNonCaseSensitive (SNA)=0, i.e. to the previous default, in order for the c1content column in table ftsitem_content (=also needed for plain text export, cf. our conversation in this forum at the time) bearing regular text).
I have now re-installed UR, v14 (i.e. replace v13), by just "overwriting" the previous installation (v13).
I have then checked the SNA sub-key, in order to change it to 0 again (from alleged value 1)...
and, it wasn't even there!
So I created it anew (DWord 32bit, with value 0: I know what I'm doing), then rebooted and checked the registry again: It was correctly there, and at the correct "abc" position.
I then opened UR (v14) and made the following tries - the BIG MOMENT indeed!
("contains keywords" is CK, "matches wildcard" is MW)
a OR b > works fine
a AND b > works fine
a b > (ok: implicit AND works as fine as it did before)
diesbezügliches > is found (quite rare word / word form, 4 correct finds), i.e. works fine
diesbez?gliches > (placeholder for the non-ascii-char) does NOT work (=no find)
> checked AS: switch from CK to MW is not done
> did the switch manually, then AS > NO find
diesbezüglic?es > (placeholder for the "h") NO find (instead of 4)
> checked AS, switch not made
> switch to MW made by me, then AS triggered > NO find (instead of 4)
es > 9720 matches (in order to check if the ? cut the search term into two, then just searched for the sub-string after the ?, but that does not seem to be the case
diesbezüglich?s > (placeholder for the "e") 90 WRONG "finds", but none of the 4 to-be-expected-ones (and no highlighting (which is "on") within those "finds"
> checked AS, switch not made (i.e. stayed at CK)
> switch to MW made by me, then triggered AS > NO find (instead of 4)
diesbezüglich* > (should include diesbezüglich, so even more than 4 finds expected) NO find
> checked AS, switch IS (!) done here (but as said, no find)
> triggered AS again, with that correct MW > NO find either
diesbezüglic[h]es > (correct "h" within []) no find
> checked AS, switch not done
> made switch to MW manually, then triggered AS > no find
diesbezüglic[ht]es > (since [] is meant to containr more than just one char) no find (instead of at least 4)
> checked AS, switch not done
> made switch to MW manually, then triggered AS > no find
I then checked the registry again: The SNA key was GONE!
Thus, it seems that when the SNA key is set to 0 (or anyway?), running UR will DELETE the SNA key altogether!
In theory, that could be also be done by something else in my system, but as said, after reboot, the key I had created, was there, then had disappeared after running UR, which might indicate UR itself does do the deletion?
Thus, the next step would be, it seems, to identify WHY the (sub-) key gets deleted, then re-do the search tries listed above, and check if any of them work better than; as said, AND and OR work fine now, but only those.
My next post will contain the UR Options (sub-) key (in its current state: v14, without the SNA key again); you might obviously want to delete it after copying the list.
|