Search problems [resolved]

[kinook]

Go to or create a text item, type some text, select it, and highlight it with the color that is desired. Future searches will use that highlight color.

Here is a screen shot of the mentioned Paine theme option.

[Spliff]

Thanks, I know that, I always have it as "Office 2010 Blue" and didn't change that. (Always show full menus, large icons no, show screen tips no, menu animations no).

So I changed the theme to some others, including yours, closed UR, re-opened it, and my search terms continue to be black on (or "in") red (background), instead of yellow background, so the theme obviously is not responsible for this. (Windows neither, I think, I hadn't changed any settings, and there was no Windows update before, just yesterday evening, and I've seen this - continuing - behavior for around a good week.) - I add a screenshot on my turn since this is quite "crazy" a phenomenon indeed; it's a search result for "gpt", from the item being displayed by single click on the item name in the Search Results pane.

[kinook]

The theme has nothing to do with the highlight color for search terms, I was just answering your question about the paint theme.

To change the highlight color for search terms, go to or create a text item, type some text, select it, and highlight it with the color that is desired. Future searches will use that highlight color.

[Spliff]

Oh, thank you, Kyle, that worked now! Nowhere in the help file it's mentioned that user formatting highlight settings also work for the search results (just Rich Text and web page editing are mentioned somewhere to which those highlight settings apply), or then that the search text highlighting color can be user-changed to begin with.

I don't have the slightest idea btw how this setting would have been de-set in my case - I never use text highlighting, so don't had any motivation to change it (I just use italicising, and then bolding or bolding plus underlining for different levels of "highlighting"), and to speak more generally, the scope and the persistance of settings changes imply a lot of trial and error, not from the technical side, but from the user perspective, considering user errors will have very unwanted effects, also and especially because of scope questions: current database, or then current and future databases, or then current and all (incl. existing) databases, and then, persistence only if the database you do the settings changes in, is the current one (and not only "open") when you close UR - lots of ways user errors or just misconceptions can have unwanted effects, whilst on the technical level, everything works as "expected".


EDIT:

In order to make this more constructive, here's an example from just yesterday. I had loaded all my 23 UR databases (I had split those I had before as far as reasonable), then I had succeeded in setting for them, one-by-one (since these settings are database-specific), to set the columns for all existing items (by search for *, then re-setting the columns) and for all my future items (by setting them for the Template "Text").

Also, one-by-one again, for every one of the 23 databases, I had manually reset the "coordinates" (not by numbers though) of the Child Items pane, FROM
Left: Data Explorer 80 p.c., beneath it Child Items 20 p.c.,
Right: Content pane, beneath it Item Parents, Item Attributes, Search (these from left to right there and just the caption plus 3 lines/rows)
TO
the same, but Data Explorer just the caption plus two lines (two instead of one, in order to give space for a possible horizontal scrolling indicator), and with Child Items the rest of the left part.

This in order to have the Search Results (i.e. the same pane as Child Items which I don't use for that) almost full-screen-height, and with it disappearing, AND automatically resizing by that (!!!), the Data Explorer to almost full screen height when I then hide the Search Results (as described above); this seemed to work fine.

Today, ALL my Child Itrems panes are back in their old position and with their old size (see "FROM" above), so I'll probably have to work on my 23 UR databases with this again, one-by-one, and not even knowing what went wrong with my assumed "scope error". It's very probably my mistake again, but I'm not happy about the fact that UR has me making such mistakes, without any warning (upon closing the database(s) in question for example), let alone some possible hint WHY this will not be persistent. (My (unique) pane "layout" is identical in all my existing databases since I did it manually (with success at the time) for the then existing ones, and created the additional ones from a "specimen" one I had created with the then-wanted settings and layout; obviously, this is only possible for newly-created databases and will not "work on" the existing ones.

I currently suppose that it might possibly have missed because of some "minimal size" for the Data Explorer upon saving / new loading, but I then would have liked to get that information when resizing the Data Explorer to so tiny a format, instead of my new format for it just not being stored beyond the session. Or then, it's another system(at)ic "scope-and/or-persistence problem" I'm not aware of...

[Spliff]

(See my post immediately before this one.)

I understand that the systematisation of "Scope - current database" vs. "Scope - all databases (if current database is the current one when next closing UR), within the code and within the menus, would make necessary lots of recoding, but perhaps, a list(s) page in the help file could clarify this?


When I spoke of my new, and systematized, column choice, above, in the Child Items / Search Results pane, I in fact spoke of "Item Title" only now, since, unfortunately, I had come to the conclusion, for my and very probably also general use, that the "Parent title" column, in practice, is of very limited use: When you have multiple search results, then the indication of the "Parent title", more or less deep-down within the tree hierarchy, most of the time will not help you for identifying the sub-tree / sub-area / whatever real sub-part of the tree the search result is in.

Instead, I would like to suggest the introduction of a column - which would thus be to introduced into the database table as well - "area" or the like, and which would retrieve the first level just below the database's source level.

According to the user's database(s') split-up, this information would be more or less helpful indeed; I have databases with just a low 4-digit number of items, and then (very few) others with about 50,000 items, but even in the latter, there are some 50, 60, 80 first-level "areas", and whilst in this situation, the above-mentioned new column information would not be too precise indeed, it at least would clearly indicate the "area" the search result comes from / is located in, and that would be tenfold the usefulness of the current "parent item title" column in / for most use cases; if your database isn't but 2,000 items, e.g., then, of course, this "area" info may be very precise indeed.

Such a new column = record field for every item would obviously serve to facilitate the browsing thru numerous search results, as also would, e.g., the extensive use of user-defined keywords, but the user-side(d) introduction and maintenance of the latter would be a very high work load indeed; being able to identify the "area" within the database in question, for each search result, would greatly facilitate the user-side(d) "weighting" of any search result, even in the absence of some "AI", judging, instead of the user, about the alleged relevance of every search result, when on the other hand the introduction of other search terms, in combination with the "main" search term, could unwillingly exclude very well "wanted" / expected search results indeed.

I advance this from some 6, 7 months+ of practical experience with a comfortable 6-digits number of items in UR, now spread over more than 20 databases, so I'm absolutely sure of the usefulness of such an additional "column", and generally speaking, any searching is about including ALL possibly relevant search results, BUT then also about fast discarding irrelevant search results from the lot.

Such an "area" column, i.e., for each item, the ID of the (technically,) second-level (primal) ancestor item, and its resolve into the corresponding title of that ancestor in the columns displayed to the user, would obviously work very differently than the "Limit search to the selected item" option in the search dialogue, since the latter only would display items which are items of a SINGLE such sub-tree of any indentation level, up to the "area" (level 2) in case, and to make real use of that, the user will be forced to create deep sub-hierarchies, whilst minimizing the "areas" number, i.e. the number of level-2 items (directly under the source item) in each database, or then to make several such "focused" searches, for several such ancestor items / sub-trees, in a row, and without the possibility to gather the finds.

If, on the other hand, the user can make a general search within the database, but then gets the indication of the "area", for each item, (s)he will be able to quickly decide which ones of the possibly dozens (or more of) items found by the search will be relevant to their task at hand, and without (!) the risk of discarding "valid" search results, a risk that would prevail by trying to better "focus" the search by adding additional search terms which should also be present within the items' title or text; in this respect, it should be remembered that UR's search does not allow, and understandibly so since this would largely increase the index, not speaking of the necessary coding, to include only, or then exclude, items of which the parents or ancestors of any level contain, in their titles (!), specific search terms, which would certainly be an ideal solution to this very general problem not limited to UR.

Again, it must be noted that the suggestions would not produce similar results to the aforementioned "Limit the search..." option, but would produce a much broader data set, from ALL relevant "areas", not just from ONE, as that option does, BUT with, more or less precise, indication of the "areas" they come from, thus allowing the user to spread their data "horizontally" in a way, holding the respective hierarchies quite flat, and getting relevant search results in spite of that, whilst the current, option solution to "focus" the search scope, forced them, in fact, in consequence, to create very deep hierarchies, by minimizing the number of level-2 items in each database; at the same time, and in consequence again, this leads to "combination" of data within the same "area" (or then, one or several indentation levels deeper) which should be held distinct, i.e. as child items of different parent items.

This conceptional problem can be greatly (!) reduced by making available, in the search results, of at least the corresponding "area" title (level-2 item title text), whilst the indication of the respective deepest-down parent, instead of the highest-up parent just below the source item, as done currently, most of the time, will not bear any relevant information.

[kinook]

There is a Lineage column which gives all of the parents of an item.

https://kinook.com/UltraRecall/Manua...attributes.htm