View Single Post
Old 04-25-2021, 11:00 AM
Spliff Spliff is online now
Registered User
Join Date: 04-07-2021
Posts: 104
Thank you, Kyle! In fact, that option was checked, when in practice, I would only need that very rarely, most searches being a full word or a word begin, and "then phrases". Will check if this problem will show again, even before my unchecking the option, it went away more or less.

It seems that my searches are much faster now, it always takes some seconds instead of being immediate, but it's way better than stated above. On the other hand, I don't quite understand this speed progress, since before even my search stated above, I had done "Compact and Repair", together with "Enable enhanced full text", so this should build up the index, which would then be there, and without that index only built up gradually, over days or weeks?

I didn't encounter any more crashes (as described above), did not do any very "big" searches anymore, but I continued to encounter "off times", i.e. 20, 30 seconds or so, of UR remaining non responsive, after searches with hundreds of results. After those "off times", UR reacted normally again, though.

I don't see any option to prevent UR from starting the search before I press ENTER in the search line, or click the search button. This way, I again and again make the mistake to first enter the search string, and then while the search already has started, I specify the search, for example by "only the current item/subtree" or "only titles", and then I have to start a new search. Could you implement such an option? (I did not find any, the only "automatically start search" option I found being for saved searches.)

Also, the search seems to start in the way of "search as you type" which always irritate me since a shorter search string will obviously provide more hits than a longer one, and that means that the search pane partly fills with unwanted results which then will be deleted again. Could you implement an option by which any search only starts by pressing the button or the ENTER key? Obviously, this would only be needed for users who wanted some automatic start of the search to begin with.

I suppose that GLOBAL search for special characters is not possible. (?)

But is LOCAL search for special characters possible? With the default content / rtf component? Or with another rtf component available for users in UR? Is it possible to look out for tabs (by a special character combination? \t or ^t do not work, the routine does not "understand" that it should search for a special character here), for \r\n, \r, \n?

Especially in search-and-replace: Would it be possible to do such a LOCAL search-and-replace, for special characters? This would make sense for replacing multiple blank lines for instance, or to replace combinations of spaces and tabs by just tabs, and so on; currently, the user needs to export the content to MS Word or some other RTF editor, make the changes over there, then reimport into UR.

I get that global search-and-replace is not possible, especially because the rtf content is in blob format, whilst global search does not search in the original data but on plaintext copies of them, so that global replace in these copies would not change the original format. But would it be technically possible to implement some "group search-and-replace", which would only work on the currently listed search results? For exemple, when I would like to globally replace aaa by bbb, I could globally search for aaa, which would give a list of all items which, either in the title or in the content, would have aaa. Then only, this new search-and-replace would be triggered by the user, "replace aaa by bbb within the found / selected items", and this would call the regular, LOCAL search-and-replace dialogue, for the first item within the search results list, and this dialogue would ask for every replacement or not (choice of the user, since it's the current dialogue, as said, and the choice would obviously depend on the risk if there is some aaa in other contexts than the one where the (sub)string would have to be replaced, or if it may safely replaced since there is no such risk of unwanted replacements), but then, when the end of the current item is reached by this (i.e. when there is no further replacement to be made within the current item), the new routine to be implemented, would automatically apply the standard, local search and replace dialogue (be it left open if possible or automatically closed and reopened, if technically necessary to do so) to the NEXT item within the search results pane, and so on: This way, the user would not have a global search-and-replace, but they would be able to continue their Yes/No decisions over perhaps 20 or 50 items where the replace should take place, without having to manually open 50 items one-by-one, and then manually open, and close the local dialogue, i.e. the transition of the local search-and-replace, from one found item to the other, would be automated. Would that be possible? Since, the original content being stored in blob format, the user can not even replace (sub)strings within the content (just within the titles indeed), by using an external SQLite browser.


Speaking of current version and "Match anywhere in word by default" off: Search results are immediate now!

Last edited by Spliff; 04-25-2021 at 01:42 PM.
Reply With Quote