|
|
|
|
#1
02-17-2024, 02:00 PM
|
|||
|
|||
|
It seems to me that the core problem with your Advanced Search construction currently lies in the fact that the whole "list" is treated as a block condition, and with the implicit "and" thus as a SUB-condition for the "Search for" string above the block; this fact makes that for many compound searches, the "string search" will have to be placed within the "list", while the "Search for" string remains empty, and then, adjusting the string to your current search needs - all other "list" rows remaining unchanged for that specific "Advanced Search schema" - is far from easy, i.e. time consuming.
Thus my suggestion above to logically treat the Search-for field as just another, UN-indented "row" of the "list", adding the and/or switch also to the first "list" row (string-field condition always "global" then, not for title-only and similar, which, as said, makes this solution non-optimal, but so much better than the current construction all the same): string-field condition and/or other non-indented condition(s) __and/or indented condition(s) ____and/or (another block of) indented condition(s), and so on. Obviously, it is possible to programmatically change string values even within the "list", here the value in the very first "list" row: special-key:: ; to be pressed when the title of the advanced-search schema is selected send {tab 5} sleep, 200 send ^{home} ; to assure focus gets back to first row in case ; send {down} ; for second row, or {down 2} for third row, etc. sleep, 100 send {end} ; set focus to row's value field sleep, 100 send {f2} ; EDIT: you want to UPDATE this value, so leaving the F2 out would not have been the very best idea here ;-) return Trigger the special key (which in other apps can be used otherwise), then enter the string, then 2 "returns" will trigger the search; of course, that first row could be a title:string condition or similar. It's ugly, but works: the user should adjust the width of the "list's" value column, obviously, making it as large as possible; fortunately, that width adjustment is persistent (if the user takes care of adjusting it when just 1 UR db is loaded). In the end, certainly most searches could be done this way: Not using the "Search for" field, but using the very first "list" row for the main (global or specific) string condition instead, and then, of course, putting MUCH care into the "condition blocks", separated by different "list" indentations (parentheses would have been easier indeed). Last edited by Spliff; 02-18-2024 at 01:01 AM. 
|
|
#2
02-25-2024, 02:34 AM
|
|||
|
|||
|
After some practical use, I've not been happy with my solution(s) above.
1) Core items (which regularly would be in level 2) > together with the (inter-) titling, in level 1. The visual aspect (see above) is top-notch indeed (for special use cases that is), and the tree-preserving search results (which exclude further-down level "finds") are satisfying, too; the fact that ALL inter-titling here is just ONE level (whilst ordinarily, they would be spread over 2, 3 levels) also is acceptable in those special use cases. The problem lies in the navigation, though: Since core items and their "conceptional parents" are at the same level, the icl (item command line) of the former does NOT contain the latter, and that makes navigation cumbersome (but not impossible): My system relies on markers, so the titles bear not only "bold" flags but also (here) a leading dot, and then, the titles are named in a way that their very first "normal" char (i.e. the one after the dot) is unique in this construction; thus, for navigation (or for moving items), it's possible indeed to go to the root item ({home}), then to send ".f", to go the .f title, then to send "e" to go to the item Esomething below title ".f"; since it's a macro, you would not press 4 keys (home, dot, f, e) but "just" 3: specialkey, f, e - obviously, this macro doesn't really help if again and again, you want to STAY within your current "sub-tree", i.e. within the range of your "current siblings", i.e. those which have the same "parent", ".f" in this example. If you just press "e" instead, you will probably go to some "e" which, in the tree, is below your current position, below some title "h" in-between; thus, you would want to go to the "parent" item first (i.e. the title "above" your target item: ".f"), then you would want to go to its "child item" "esomething". In this situation, in a regular construction (fsome or .fsome = level 1, esome = level 2), this would be easy, even without a macro, since you would simply enter {left} = go to parent, e = go to esome = just 2 keys, AND you would not need to first think of "what name is the parent?", whilst in the "everything in level 1" construction, you would have to check or remember the "f" for the "parent", in order to first go to it - and then you will have to work this way all day long in your "everything in the same level" construct. Thus, this is visually pleasing, and gives the wanted search results, but it's not realistic in real life. Thus, I have adopted a "more regular" construction, which visually is awful, but which is the only construct you can currently really use if you need tree preservation of the search results: Root (level 0) .T (level 1, abbreviated so that it's less awful) __.Title ".T..." in full string (all these in level 2) (edited) __Core item __Another core item ____(on level 3 and deeper down, other items in case, obviously) __and so on .A (level 1, abbreviated again) __.Another title, ".A...", in full string (level 2 again) (edited) __And your core items here (level 2...) __etc In other words, I duplicate the first char of the titles into a higher-up level (level 1), then search for results just in level 2, and get the same search results as before, BUT can now do - {left} e (2 keys) for getting to item "esome" "within" my current "f" siblings range, and, of course, when I want to go to some item elsewhere, I can do - specialkey h k (3 keys to go root, then go to .h (for hsome, and make that the first visible item then), then to ksome. Please note that without the leading .title dots, such a navigation would not be possible but if you systematically collapse anything (UR has a setting for doing this even automatically if your really want to do this), which will seriously hamper your "overall view" though. (As for the search, see below.) (EDITED above: "__.Title ".T..." in full string (all these in level 2) (edited)" I first had left out the leading dots here, trying to hold it as simple as possible, but that was misleading, since in fact, I replicate the dot: Since CharSearch navigation is "top-down", the ".A" will be navigated to (level 1), not the .Afulltitlestring (level 2) (ditto for {left} for "go to parent item"), but after that, any "a" will navigate to the very first ASomeItem (item starting with "a"), so it would be misplaced to "sacrifice" the "a" for AFullTitle when replicating the leading dot (necessary for the abbreviated title only), making it .AFullTitle instead, does not do any harm but preserves the possible use of a leading "a" (in this example) for any core item in that "A" title's child items range. Thus, technically, "AFulltitle" (level 2) would be sufficient, but wouldn't be advisable.) 2) The Search Rows I have explained above why the current AS (advanced search) construction, with "string by input field" plus "AND BLOCK" condition to that string condition is unusable for many real life search tasks, so I suggested, for those situations, to use the very first AS ROW for the string condition, but that would make control-home for first row, then {end} to activate that row's value column: It's easier to use the very last row instead, since a control-end will automatically activate its value field (in one step, instead of two); also, in my example for the task above (1), compare the two (functionally identically) constructions below: obviously, the second one (in this case at least) is more comprehensive. 3) Currently no "Discard row condition from search" Whilst the conditions AND and OR are available by drop-down, the NOT condition is available by check-box; what's missing though: a checkbox for quick-n-dirty discarding (!) a row's condition (which obviously is not NOT but "is irrelevant currently"); technically, such a row would not be retrieved while the code behind the AS interface builds the AS's select-string - so technically, the implementation would be easy. Obviously, this would help for standard ASs with "variants", so that the user would not have to multiply stored ASs but could choose the applicable variant "on-the-spot". And here now the two screenshots both illustrating 1) and 2), the second one, as explained in 2), obviously being preferable in the situation explained in 1) and possibly even beyond: Last edited by Spliff; 02-25-2024 at 03:16 AM.
|
|
#5
04-01-2024, 02:25 AM
|
|||
|
|||
|
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) ;-)
|
|
#6
04-16-2024, 01:59 PM
|
|||
|
|||
|
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"! .
|
 |
|
|
Hybrid Mode
