[Spliff]

EDIT:

1)

I got the idea to run UR from a USB stick, to PC 1, finally (it didn't work but after I had closed UR on PC 1 and ran it again from the stick then):

It opened the UR DBs I had last opened on PC 1; I QS-searched
a OR b
> it (almost*) correctly displayed the items which contained either a or b
*="almost" since it only failed to also list, as search results, two NEW items, one with a, the other one with b, created by me immediately before the search, i.e. editing the DB (on PC 1) "from" the stick, so this "almost" obviously is a "fts index not updated" problem: It seems that when running UR from a stick, the DBs should also be on the stick, not on the PC.

Thus, I again de-installed UR from PC 2 (on which I don't need it), again incl. "Delete customization data? YES" (= just as I had done before situation d) described above), then checked PC 2's registry for the UR key, in order to verify if before above-described situation d), the UR key had been deleted or not, so that the new UR install on PC 2 had re-created the registry key, or had just updated it: The key is completely gone, so also situation d) had been after a complete, "fresh" new UR re-install (and without copying the registry key or parts of it, or any of the 4 UR ini files from your list, or any parts of it).

Thus, situation d), AFTER a complete UR re-install, without (!) any settings beyond the default ones, AND showing the same problems as in situations a, b and c, seems to prove that NONE of my UR settings (i.e. be it in the reg key, or in any one of the 4 ini files), seems to cause the problem, and on PC 2, NO other program had been running in situation d).

Thus, I really don't know where to search for possible causes of this awful problem - and running UR from stick is very slow (but could be sped up somewhat by buying a better stick).

2)

Off-topic here: MyInfo / MyInfoApp (according to the "manual" available on their site) seems to do something what you do, filtering in the tree pane ("Data Explorer" in UR), but whilst you only allow for that filtering by flags, MI/MIA only allows it for text-within-title, so this text-in-title (i.e. not also within the content or in other elements) might also be a user's "tag"; thus it's obvious that their tree filtering is - I hate to say this! - FAR superior to UR's indeed, since IF the user knows about that limitation, they can put "textual core info" (tags) within the titles, then filter the tree by those:

- UR: 20 flags, MI: hundreds of different tags / sub-tags in case

- UR: 20 flags combinable by OR only (by clicking together them by AND in "Tools-Flags" > only ONE flag possible per item), MI: those hundreds of tags also combinable by AND (several (!) tags / title-sub-strings possible per item)

Thus, MI doesn't have "tree filtering by general search" either (and neither has RightNote, as far as I can see from their help file: trial reverts to free-version, and then you can't trial the "pro" version anymore, even many years later...), BUT by "search in titles" at least, which multiplies, as explained, the filter possibilities in comparison to UR at least.

(Also, refer to MI's "manual" (number 5.1 in there) in order to compare how they accept users' "search" input, and which is obviously the only really good way to do it... as for the search results' presentation, it's then not so brilliant indeed, and RightNote's are simply awful in comparison...)

It would be really a good thing to think about amending filtering, be it in tree or in search: My original assumption that it was more or less "standard", was very mistaken, BUT it IS standard in editors, grep tools: The original text's order is NOT scrambled by them, by/in filtering, and the additional milliseconds due to to the additional processing would be happily borne by the users: always as an option, the "regular" = faster representation being "tree-destructing", so it would be the user's decision to wait a little second on top, for MUCH better search results - also bearing in mind that the necessary RE-sort, BACK to tree-order, and AFTER the collection of the search results, could certainly not take THAT long, considering normal searches would bring just some, or some dozens of results, rarely hundreds, almost never more... and then, it would always be possible to include some code lines for, "if result_count > 500 then message 'Results not tree-sorted since too many' instead"... ;-)