|
|
#1
02-11-2024, 04:35 PM
|
|||
|
|||
|
Advanced Search with tree preservation (sort of) - HINT
As I said some months before, I absolutely need Filtering in correct tree-order, and since Tree-Filtering just applies to flags, I also need some filtering by Search, for other item attributes.
Thus, in view of the problems we discussed, with "Search - Sort by Lineage, then by Tree Order" - here, the longer paths are not interwoven with the shorter ones, but placed behind the shorter ones, so tree order is not respected -, and since I need tree order preservation absolutely, I took out sub-trees to new UR DBs (so this augments the number of my UR DBs even more), then "flattened out" the hierarchy in that sense that in fact, I "flattened IN" the level 2 "core items" INTO the range of the level 1 "section" titles, preserving somewhat visual "hierarchy" with separator lines plus bolding (understood that only the "titles" are black-bolded, other items being only colored / italicised in case, but never bolded), i.e. previously: 0 - source item 1 - title _2 - some item __3 - some subitem(s) here _2 - another item (any formatting) 1 - another title _2 - some item etc now instead: 0 - source item 1 - title 1 - some item _2 - some subitem(s) here 1 - another item (any formatting EXCEPT bold) ______________________________ (separator line (otherwise empty item)) 1 - another title 1 - some item etc ______________________________ 1 - another title 1 - some item etc etc ______________________________ (bold line here, not replicated by the forum software) Templates Recycle Bin INBOX etc. (Understood that you can further strenghten that (purely visual, not also technical) "hierarchy" by putting some "section titles" into CAPITALS, and / or can bolden (or not) the separator lines, as well as use shorter and longer separator lines (e.g. 20 underlines "_", or then 40 instead.) NOW, since the "titles" are "bolded", i.e. they bear a specific flag, you can systematically search for them, in order to see the structure, AND you can search for your real target items, viewing the results, correctly "situated" within that "tree" structure, even with separator lines if you want, e.g. Section 1 (some title) item with "hit" another "hit" item ____________________ Section 2 (some title, NO "hit" in here) ____________________ Section 3 (some title) 3 "hit" items here ... ... ____________________ Section 4 (some title) etc etc Now, all this is in perfect "tree" order (since technically, it's not a tree but a flat list), but of course, this only works this neatly* as long as you only search for results within this flat list, i.e. within the "core" items which, to this effect, have been "promoted" to (the original "title" level,) level 1. (*= whilst also including search results "deeper down" would ask for another search code, and then those results from "deeper down" would not be included in the (simili-) "tree" schema above, but listed below that, i.e. without any "location" indicator) Now, for the above to work, you'd write an Advanced Search as follows: Item - contains keywords - YourSearchTermHere or Flag - equals - Yellow (or your respective "Bold" flag) or Item Title - matches wildcard - _* ____and Indent Level - equals - 1 (you indent this "and" condition) or you do it the other way round, indenting 3 of the 4 conditions: Indent Level - equals - 1 ____and Item - contains keywords - YourSearchTermHere ____or Flag - equals - Yellow (or your respective "Bold" flag) ____or Item Title - matches wildcard - _* and finally, if you want to see ALL occurrences of your search term, of which at least the "core" item "hits" within the "tree" structure, the "rest" below: Item - contains keywords - YourSearchTermHere ____or Indent Level - equals - 1 ____or Flag - equals - Yellow (or your respective "Bold" flag) ____or Item Title - matches wildcard - _* You see here ( i.e. in this blatant example of "shaping your work to the software", instead of it being the other way round ;-( ) that the (very first of several ones, in case) "contains keywords: ..." condition (and independently of it being for Item or Item Title, or possibly even another attribute / column) within the Advanced Search (AS) , should be available by some additional input field (and which is then accessible by Tab and, in particular, macro-accessible by its own control name, e.g. "Edit11" or similar), the respective value within the AS "list" then NOT being your specific search term anymore, but "[entry]" or similar: Since again and again, users need the same stored searches, but with an individual (i.e. ever changing) search terms, and fiddling with the value within the "Value" field in the "list" here is very time consuming, and copying your 10 or 12 most frequent search terms into 10 or 12 otherwise identical copies of the same search schema doesn't help but to some degree, beyond causing lots of unnecessary clutter. ;-) EDIT: I only mentioned it above ( referring to https://www.kinook.com/Forum/showthr...hlight=lineage ), but of course, that's the way it's to be done: for tree results, select any columns, but incl. Lineage (sort by: click the header) and Tree Order (sort by, secondary: control-click the header); and, of course (but with much less "clarity"), you could preserve that special "tree" within your original UR db (instead of creating a new one for it as I did), then adding a condition "Lineage must contain ..." (and adjusting the indentation level condition of course); this would also work for several such special "trees" per db, but I want it "neat", so I created additional DBs instead. And, of course, making available QUICK entering of the MAIN STRING CONDITION, within ANY Advanced Search (= stored compound search SCHEMA, but for INDIVIDUAL main strings = search terms), would be a tremendous step ahead indeed: Then, HOW to do it technically? Above, I mentioned the "first currence" of the condition, "contains keywords": this would be weird both for "the developer", Kyle, AND the user (for construction of their respective search schema). Much easier for both: Allow, within any STRING value field in the list (wherever it is within the search construct), a special entry, e.g. [§§§] or similar (fixed by the UR code, then to be entered by the user exactly like that), and write the necessary code (easy) which "links" that special entry to the current content of the "variable string" field (above the "list"); and (also easy) don't do trigger the Search but an error message whenever the user has put in that "special string" in MORE than just one string value (or any other) "list" field; alternatively, add an entry "Individual value" to the drop-down in the "list" (by "list" I mean the "click-together" part of the AS) wherever a string (or number) entry is allowed (i.e. whenever the drop-down contains an entry "contains key word", or similar for a numeric value); then again, if the user has chosen that "Individual value" more than just once in their "list", upon "Search", instead of triggering the search, trigger the message "Just one value as "Individual" allowed. Please rectify". That way, the code remains neat, AND the user can start to regularly use stored AS schemata for their individual, always changing search strings! ;-) Last edited by Spliff; 02-12-2024 at 01:30 AM. 
|
|
#2
02-12-2024, 09:14 PM
|
|||
|
|||
|
I'm not sure that I am completely following that, but could you use the quick search filter field within an Advanced Search to do that?
Can you provide an example .urd file with further explanation or demonstration of what you are requesting? Thanks.
|
|
#3
02-14-2024, 03:04 AM
|
|||
|
|||
|
Thank you very much for your question: In fact, I had left out the problems arising with the combination of the "Search for" field, and then the "list conditions".
Unfortunately, the string condition within the field has to be fulfilled by each result sine qua non, AND then the "list conditions" (lc) have to be fulfilled, as a block, either, i.e. the implicit code is: (yourstring) AND (whatever your other conditions here), in other words, there is a big AND between the "Search for" field, and the "list", and that's why, e.g., at the start of the very first "list" line (and different from any other list line), there is NO "and/or" toggle, since the whole list is considered "and". I admit that for some compound searches, this (very limiting) construct is fine, but for others it's not, e.g. whenever you want, as I do, in my "simili hierarchy within a flat list" Advanced Search, have any (or, as here, even several) "list" conditions alternatively to your (main) string condition, not "above on" it, so, if I want to also display the "construction" items (i.e. the inter-titling, as in my example above), I have to type the search term as just another list element, the "Search for" field being useless = left blank. In this context, it's also of interest to remind that a simple toggle "and/or" between the field and the list would not resolve the problem, since then again, the whole list would be considered as ONE (not additional anymore, but alternative) condition, and thus would now display too many results, instead of too few. (Since in my example, the "indent level" condition is additional to anything else, whilst the other list conditions are alternative to the string condition.) That's why I had suggested an additional field "Individual", to contain, in case, the individual string (or perhaps number, in case, for address, or year fields, or similar: individual data vs. "schematic" data, within the other "list" fields) for any (but just one) list field which (by the drop-down list, so that would be easy to add to the drop-down) allows for either string or numeric input: Then, in order to have an input field, the last column in the "list" would mention "IND." or somewhat (selected, as said, by the respective drop-down entry), and IF there is just ONE such list field (for which the user has selected the "Individual" field content), the input of the "Individual" field above, between the "Search for" field and the "Start" button (or even just above the "Search titles only", etc. block of check boxes), UR would replace the "IND." marker by the content of the "Individual" field above; - user chose "ind." for more than one list field > Error message asking for "just 1 such list field" - user chose "ind." for one list field, but without content in the "Individual" field > (either error message, or, and preferably,) value / condition is excluded from the sql search string - there is (previous) input in the "Individual" field, but no condition with "Ind." > "Individual" string is simply not included into the search, since there is no condition which would include it This arises the question if the "Search for" field could probably be used instead, with adding the usual "and/or" toggle also to the very first "list" row; default being "and" (as usual, too), and the "and/or" would only apply to that very first "list" condition; you would remove the global parentheses around the "list block". The problem with this alternative would be twofold: Error-prone on the user-side (as is the current "package" indentation within the list, instead of parentheses, indentation regularly indicating subordination, which is not the case here where it's just grouping); and then, the "Search for" field currently only allows for "search string everywhere within the items", neither "title only" nor numeric fields, in other words and e.g., it doesn't allow for "title:Search term to be searched just in titles", which would be a frequent (!) search, especially if users do tagging in titles, and it's obvious that almost every such "tag search" would be for different tags or different tag values, so this would be quite inferior. In contrast, my problem solution above - needing an additional field - would both be much neater (i.e. less ambiguous) for the user, and would also allow for fast (!), individual, compound searches of specific title data, and of data within numeric, or then specific string fields, i.e. its application scope would be much broader. (And at the end of the day, the introduction of an additional field would probably even become the very first step for some day allowing sql "select" strings, allowing for quick individualization of more than just one condition? ;-) (User-side AHK input box, then a macro writing the necessary select strings. Would happily share.)
|
|
#5
02-14-2024, 11:46 AM
|
|||
|
|||
|
A) First, you have the input field "Search for:": This is just for general = item-wide string search, can not be used for "search title", for "search item notes", or any other specific field search.
B) Then, you have buttons Start, Reset, Copy, Quick<, B2) and to its right, there is room for a second input field, albeit not as large as the "Search for:" field. C) The "list", with and/or (except for the very first row/element), Item/Attribute, Not-toggle, Comparison, and Value fields. In here, the "Comparison" field is filled by a drop-down menu which just offer those elements / menu entries which make sense for the respective "Item/Attribute" selection, e.g. "Comparison: contains keywords" is present for "Item/Attribute: Item", and others, but not also for "Item/Attribute: Access Count" (since "contains keywords" would not make sens for that); on the other hand, "Comparison: less than" is available for "Item/Attribute: Access Count", but not for "Item/Attribute: Item" - and so on; when "Item/Attribute: Has Children" though, the "Comparison" drop-down just offers "exists" and "equals", and the "Value" column in the list doesn't allow user (string or number) input, but again provides a drop-down, for "yes/no" here. Thus, it becomes evident that for adding an additional entry "Individual" (or similarly worded) to many (but not all of the) "Comparison" drop-down menus, would be easy, since that additional entry would apply to any "Comparison" drop-down even today, an entry inviting to enter either a string ("contains keywords") or a number ("greater than", etc) is present. The drop-down "Individual" choice by the user would then automatically fill the "Value" field of that "list" row with a fixed "Individual", not allowing for user input, and if the user wanted to change that, and enter a manual value here, they would have to select another "Comparison" drop-down entry, making available the "Value" field available for manual input again. Upon "Start" (by enter, or pressing the button), the code would check if there are more than just one "Individual" entries in the list B), and if there are, instead of triggering the search, it would ask the user to change those "Individual" rows to fixed ones (i.e. with a real value within the row's "Value" field, instead of invariant "Individual"); if there is only just one such row though, the code would retrieve the content of field B2) IF there is one, and quickly check if the format applies: just a number if the "Individual" row asks for number input, and any string if that row asks for string input; if there is a string for a number input row, the code would give an error message, along the lines of, "'Individual' input can't be a string here; enter a number, or change 'Item/Attribute' or 'Comparison'"; if there is (residual) input in B2), but no "Individual" row, the sql select is constructed without the B2) string; if there is an "Individual" row, but no data in B2), then, similarly, the sql select is constructed without the "Individual" row condition. - My example above shows it very clearly: Really "individual" searches have currently to be made by constructing the search within C), not by combining A) (since A doesn't allow but for too general search scope: the whole item, and for too few logic combinations: no grouping / parentheses allowed in A) with C), and that means often, the user must enter even the main search string of such compound searches within C (where it's cumbersome), instead of entering them in A). - It might be of some interest, as an alternative to the above, to add the and/or even to C's first row, and then (instead of treating A) and C) as "A AND C" (block-wise)), to imply a "group" just between A) and the very first rows in C) while they are NOT indented, so A) this C) and that or other ___or these ___and those would not be translated anymore to (this) AND ((that or other) OR (these and those)) but to (OR having precedence over AND) (this and (that or other)) OR (these and those) In other words, on the logical level, A) would become a part of C), like any row 1, 2, 3... in C) while these rows are not indented. As said above though, this alternative (avoiding B2) would not resolve the problem of A)'s too global scope, making e.g. individual title:search-string search impossible: the values for string-in-title search would again have to be entered in C), contrary to the first alternative, with B2): In C), the user would select, for title-search, "Individual", and would then enter the individual value for each new title-search into B2); ditto for any other string or numeric attribute. That way, the user could create several schema "advanced searches", for different search situations, BUT then enter the individual search string within B2). Or then, they could enter it in A) IF A)'s functionality was greatly enhanced, allowing for input like title:search-string notes:search-string, the code then resolving such keyword:string combinations into the respective column search elements: Such compound searches within the same input field would be a first step to allowing parentheses in there, and would indeed, at some time, make C), the "list", redundant insofar as the "power user" was concerned. Obviously, B2) is, code-wise and for the user, the simplest solution to the problem; the current "A AND C" (even with an added toggle for "A OR C") though, logically separates the "main search term" from the rest of the conditions, whilst - as shown above - more elaborate compound searches ask for more intimate integration of that "main search term" into other conditions: My suggested solution, B2) (which, as A does, should also allow for AND and for OR), its value being retrieved by an "Individual" "value" marker in any C) row (as long as it is the only one of its kind), provides that: easy enter and change of the main search term(s), AND permitting that this "string condition" can be placed anywhere in the "select" code.
|
|
#6
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.
|
|
#7
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.
|
|
#10
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) ;-)
|
|
#11
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"! .
|
|
#13
04-21-2024, 06:32 AM
|
|||
|
|||
|
There are some QS/AS designs, (a), (b), and (c) (see above, and below). For my task(s) at hand, I had found some (working!) solution for design (a), and came here this Sunday morning to share it, AND for explaining why my suggestion of a design (b) wasn't worth much, and why my suggestion for design (c) was much better indeed.
I then discovered your new design, which visually would be my design (c), so had high hopes (in spite of these hopes being turned down a little bit by your (as always, extremely concise wording)... and yes, technically, your design is (b), not (c), and yes, I cling to my solution for the time being, since design (b) (albeit looking as it was (c) then), at the end of the day, doesn't help me in any way for my current problems... but then, as said, I came a little bit late with my (necessarily theoretical) findings - now (unfortunately) being backed up by my (logically expectedly, useless) tries with v. ...17. Thus, I can't hide my personal deception, for my means, but let's hope that for some of third parties' needs at least, (b) (in (c) appearance, hoho!) will be of real use then; I very much appreciate your effort though, and yes, I hadn't "seen" in time, had been aware of the superiority of (c), but not yet of its weight of importance for my problem, and probably most such problems, except for the very last days... ;-( In what follows, YOU is the user, STRING is the string in the "Search for:" input box, GRID is the grid, in case as the grid-condition as a whole: Above, I had presented two designs, one declared as better, one as lesser: a) The then current, i.e. the previous one (i.e. before v17): String AND (implied/mandatory) Grid b) The "lesser" one: String AND/OR (= a toggle button in-between, AND being the default value) Grid c) The (in fact, much) "better" one: String (logically as Grid's "row 0") (whenever there's a grid; else it's a stored QS) AND/OR Grid row 1 (AND being the toggle's default) (technically grid row 1, logically grid's second one) AND/OR more Grid rows (as always) Now you have implemented (b), but with the appearance of (c) - which doesn't make it (c), obviously. Now: Logical (inclusive) OR (i.e. not exclusive XOR, of which we don't speak here) means, practically, MORE, tendentially (or=more, that's easy to remember), whilst logical AND, in practice, means LESS, and this paradox-on-first-sight resolves easily when we recall that both, AND and OR, apply to the conditions, not to the results, and more conditions, by AND, logically tend to shorten the result set, since more conditions are imposed on the "original" set. (In what follows, let's also remember that String can be a construct of single string, and/or string and/or string... to a certain degree at least, I haven't tried this out thoroughly, and, as already said, with AND having precedence over OR (as in the abc).) Let's assume that all "wanted" String strings are on level 2, and that you also have put the intertitling on level 2 (flag yellow=B=Bold; alternatively, you could have "marked" those Titles with a tag °t for example; in the end - we'll see this below, this tag = string solution for the Titles is even the only neat one, i.e. if you don't want to have "surplus", unwanted String "finds" - we'll come to that later) Now, in (a) which was "(String) AND (Grid)": String: xyz AND (mandatory) Grid: IndentLevel=2 (that's a valid condition since only xyz on level 2 are wanted) > you get all xyz-items on level 2 but not the Titles ( as expected, so you add: ) OR Flag = yellow/Bold > you will NOT get more results here (i.e. the bolded Titles) since OR is just another condition for the xyz items (which doesn't make sense (sic!), but since it's OR, it will at least not cut in your xyz results either); thus you add: AND Flag=b > cuts into your xyz results, i.e. will only show any bolded xyz items (whilst you wanted additional results instead, and anyway, you don't bold any of your "regular" items (but format important ones otherwise), since you don't want them to be visually mixed up with the Titles (which, necessarily = in order to maintain the tree order within the search, are within the same level 2 as their (conceptual, but not also technical) "child" items) BUT what you CAN then (always in (a), or even now in (b), whilst NOT (being able of) taking advantage of (b)'s first-grid-row' AND/OR toggle): Not only bold the intertitling (for your eyes only, haha), but also add a °t (technically needed now), to their title, or to their text, or wherever (or some other, similar STRING tag, obviously) and then: Columns/Sort: Title0, ParentTitle2, TreeOrder3, IndentLevel1 String: xyz OR °t (the " OR °t" part by control-Enter in String) Grid: AND IndentLevel = 2 > perfect result and thus my chosen solution, possible both in previous (a) and current (b), if, like me, you want all xyz items of level 2, together with their intertitling (and nothing else, e.g. xyz-items of levels>2 (since we have found that it's impossible to also sort these into the existing tree structure)) If you try, in (b) now (i.e. with the leading OR made possible), to "hold neat" the String, you will have to live with unwanted finds BUT which are BELOW the wanted ones, so that's technically possible, too, just a question of your preference, you either have neat search results, from my solution before, or you have a neat search string, as follows (Columns/Sort as before): String: xyz Grid: OR Flag=b > again, you get the wanted results (i.e. the level-2-xyz with their intertitling, and we see here it's a real OR indeed, not a XOR), but below those, all other-level xyz finds (always given that level 1 is just there in your db for the (necessary) "ParentTitle" sort and doesn't contain any xyz-strings/items, obviously) AND IndentLevel=2 > as without the AND since the AND (=the indent level) is just another condition for the Flag, NOT also for String (xyz, and which is what you will have wanted though), so, here again: 2-level-xyz's and Titles correctly ordered, then all level>2-xyz-items Now you can fiddle around with these, String always xyz, then: Grid: OR Flag=b __AND (indented) Indent Level=2 > same as before (i.e. first what you want, then the unwanted level>2 xyz finds) ditto for Grid OR and AND both indented, whilst Grid: AND IndentLevel=2 __OR Flag=b and __OR Flag = b AND IndentLevel=2 > both show only the level-2 xyz items but no intertitling (and thus, it would not make sense to then fiddle around with the sort-order): Since again, what looks like (c), is (b) in reality, so there is no way to add, in the Grid (sic!), BOTH 1) any additional condition(s) for the String, AND 2) any alternative condition(s) for the search but NOT also affecting the String condition, at the same time: it's either 1), with the first Grid row starting with AND, or 2), with the first Grid row starting with OR: No way out of this in current technical (b), and whatever you try: "It's the logic, stupid ;-)", in order to dare fudge Marilyn Monroe, or in other words, if you need a "mix", try to replace some non-String conditions by additional, "or", String conditions in case, so that the Grid can then either work independently of those (OR) or affect ALL of the String conditions at the same time (AND, might be quite rare...). Hence: Whilst previous (a) gave the only possibility to add additional String conditions via the Grid, current (b) also makes possible to add alternative conditions to the String condition (by first Grid row OR instead of it being the default AND), but not (yet) (as (c) would have done) the possibility to MIX alternative conditions AND additional String conditions. Such a mix IS possible, obviously, if you leave the String empty, and put all necessary strings into the Grid (or with design (c), obviously, for global strings). And here's the necessary code to smoothen / speed up such searches in (a) and (b): you just enter your "original" string (here xyz) and press Enter (you would need to have Tools-Options-Misc. - "Display selected item title in window title bar" ON, obviously): $enter:: if winactive("ahk_exe UltraRecall.exe") { if winactive("distinct name of your stored search here") { controlgetfocus, s if ( s == "Edit2" ) { send, {end} sleep, 100 ; ms send, % " OR °t" ; or whatever additional global STRING condition(s) ; you need the % for the "", and you need the "" for the leading space sleep, 100 send, {enter} } else send, {enter} } ; else if winactive("distinct name of another stored search here") ; as before, etc, then finally: else ; any other Enter press in UR send, {enter} } ; else if winactive("some other application") ; ... etc else ; for any app not listed before send, {enter} return EDIT: A "typo" above (any ":" and then ")" without a space in-between translate to some smiley), and just for completeness: Possible "tag codes" (among more or less "readily available special chars) in MI do not include period and comma (.,) but are restricted to § and _ (e.g. §some or _some), whilst, as said, such characters in UR comprise the four chars ¬, ¦, § and ° (as used above). And the recently added "Exclude" checkbox also helps enormously with constructing correct grids ;-) Last edited by Spliff; 04-21-2024 at 07:46 AM.
|
 |
|
|
Linear Mode
