Two search results table bugs - when that pane is independent only

[Spliff]

First of all, since I use AHK, it's obvious that whenever I encounter problems with UR, I check with AHK disabled, so I don't risk to bother you with problems caused by (my faulty then) AHK code. Back to UR:

Since you very thankfully told me how to do it - Lineage (first ordering), Tree Order (second ordering), Item Title (into which the "flags"' formattings are propagated) - I'm very fond of the Search Results Pane (SRP): It's extremely helpful for speedy info management.

Also, I repeat it here for that fact to get it better known: When we dismiss highlighting of the search terms (that's the condition), we are able to manually edit any of the search results from the SRP, one-by-one but "in bulk" in way (and afterwards, we can re-activate that "highlighting"). So:

I have my screen in 2 halves: left = UR, with 1/3 tree, 2/3 content-pane, and, after search, vertical half of that for SRP: Thus, then, both content-pane and SRP are not high enough, and SRP is not broad enough (since I need the Lineage rather broad, in order to not become "lost in my hyperspace", and then the Item-Title gets rather narrow...

Thus, I have experimented with drawing the SRP OUT of my (up to then, unique) UR window, to the RIGHT half of my screen (which otherwise contains "secondary" applications: Firefox, dictionaries...): both the content-pane (in its original location) AND the SRP are now full-height (1440 pix), AND "full size", horizontally, i.e. half-screen-width, i.e. somewhat 1270 pix).

And here, I got into problems.

When the SRP is within UR's main window, it (well) functions as follows:

- search results are displayed

- focus is on first item in result list

- (1) up/down arrows function as expected, i.e. will navigate within search results

- (2) F2 will select and "open" the "Item Title" column in the result-list, and any edit you do then in the title there, will propagate to the title column of that item in the UR db: PERFECT!

- ENTER will shift focus to content-pane of that item (and you can edit that, within the above-mentioned conditions)

Now for the the SRP as an independent UR window:

1) (tiny)

As before, first item in result-list is selected automatically. Down-arrow then will NOT select the second item in that list, BUT will go to the content-pane of the very first item; you will have to go manually back to the SRP, and further Down-arrow pressings then (only) function as expected, i.e. STAY within the SRP, while, without switching focus, displaying the respective content in the content-pane.

(Please note that "Options - Search - Focus SRP after search completes" is selected / active in both situations, and "ditto - Select first match after search completes" is DE-selected / IN-active in both situations - whilst "ditto - highlight matches if OFF in both situations.)

2) (awful)

F2, as said, functions as expected in situation 1, but when the SRP is "independent" (situation 2), it invariably selects, and invites you to "edit" the Lineage (!!!), and that, independently of weather the Lineage is in position 1, 2 or 3 in the above scenario, i.e. even if I put "lineage" behind tree-position and item-title, I should "edit" Lineage, whilst the Item-Title remains unattainable for any editing.

(Thus, for the time being, I HAD to revert to the "traditional" setup, with the SRP integrated into UR's main window.)

[kinook]

I was unable to reproduce this behavior.

[Spliff]

Thank you for checking, but I'm positive about what I have described, i.e. about both problems, and I had encountered them with "the version before the last weekend", and now, with the freshly-installed, brand-new version, it's exactly the same.

1) It's not possible to directly "browse" (scroll) the list with {up}/{down}, since the focus is automatically reset to the content pane of the very first search result; from then, I then have to go back to the result-list, and then only, I'm free to browse the list.

2) The item titles in the list are NOT editable, neither by F2 nor by mouse (double) click, context menu (by right click) or whatever (whilst editing the titles in the list when the list is a control in UR's main window is seemless), but F2 invites to edit the lineage (!).

I add a screenshot which shows that; here, the lineage is the first column again, but as said, it's the same problem when the title column is displayed first.

Last time I had taken the result list out of its usual position, below the content-pane, to the "other half" of my screen width (where this action then creates another, specific window for the list control), whilst this time, the "original" list control was as "Auto-hide" at the bottom of my UR main screen; I then set to "Floating", then position it independently.

At the right of the screenshot, you can see the "S" in red square, indicating that my AHK script has been entirely stopped (so I did not only suspend the hotkeys).

(What the screenshot doesn't show, between the lineage (left, primal sort) and the title column (right), there's (as said above), a third column, tree-position (squeezed since just needed for secondary sort, not also for visual info).

So, I'm quite stuck now; I had really hoped you could identify the problems, at least the second one; before, I had tried, for lines as long as in this (problematic) scenario, an "Auto-hide" result list at the bottom of my UR main window, and with the same width as that, but here, two other problems occur:

- when I "go" to the content pane of some "result", otherwise but by mouseclick (i.e. by control-2 or similar), the result list will NOT auto-hide, so I need the mouse in order to hide that, even editing the content, with previous mouse use, will not change that; by pane-change by {enter}, though, I will LOSE the current state of the result-list... (and anyway, having the result list available, on the side of tree and content pane, instead of hiding them more or less, and as long as I need to work onto those results, is / would be so much more practical, than auto-hide, open-again, auto-hide...)

(btw, where the auto-hide works indeed, that's whenever I change the window, i.e. leave UR for another application...)

- this auto-hide takes MUCH too long; I understand there is some "animation", in order to indicate the special character of that pane then, but I could very well "do without" that, and at the very least, that animation would perhaps be much more bearable if it took just the fraction of a second... ;-)

Since I can't imagine that my W10 system alone - even without any AHK intervention - causes the invitation to edit the lineage... well, this gives some idea... no, just joking!... - in fact, when I then try to edit the lineage, it does nothing, so at least no harm is done... - I hope you could look into the code, in order to identify some glitch which there should be in there?

(Btw, "Rename" by selecting the command within the context menu will have the same effect, and, as already said, the order of the three (i.e. they are three in all) columns doesn't play any role either.)

[kinook]

Still not able to reproduce. Please send the info from

https://www.kinook.com/Forum/showthread.php?t=3038

including a screen recording.

[Spliff]

Have not yet resolved the problem, but want to give some intermediate report.

I don't remember anymore when the behavior described above initiated, probably - I had thought so, but I might have been mistaken - with the floating pane, and indeed, the (first, or a subsequent) "floating" of the pane might have caused the behavior, but see below - and obviously, any try to "rename" just shows the problem, but has nothing to with it -, but I have now discovered that it's the same behavior when the pane is within UR's main window! (Re-install doesn't help.)

I have also discovered an xml "Layout1" file with about 1100 lines, of which more than 1050 are for some setting 38, ditto for Layout 2 and 3, without the specifics (since I had never stored an alternative layout, and thus just around 1050 lines each.

And I have thoroughly analyzed UR's registry "Options"...

All these are obviously NOT db-specific...

Whilst every UR db comes with its own, specific table "ItemAttribute", and then, "LayoutAttribute", and it's obviously the latter one which is of the highest interest in our context here, so I analyzed that table, in connection with the table "Attribute"; I must say that programmatically, i.e. by SQL, I ever had only attributed flags, no other "table(s') update(s)" from my side whatsoever...

Thus, I have installed the newest, "mint" UR.setup version on a second pc (without UR and any UR db) which is only there in case my first pc doesn't work anymore (i.e. it's not a backup or something, just "in the waiting").

Here, with fresh UR, and without any previous UR settings, I could confirm what I had discovered, in-between, on my main pc / with my regular UR install (and where I have juggled with up to about 30 UR DBs, currently near 10, and with all the problems deriving from that situation), and so I can confirm this is regular UR behavior, having nothing to do with any possible - deviated?! - UR settings:

When I "choose columns" in that search results / child items pane (for both, doesn't make any difference), the dialog prevents (!!!) me from deleting the column "Item Title" (-5 which is preset, and which is non-user-editable according to further table('s) information ; not to be confounded with 5 - the user-editable one), and similarly, whenever I try (on the "mint" system, as well as on my "work", more-or-less "corrupted", system), to "move down" that -5, or then, to up anything else, TO the very first position (held by -5, as said), the dialog greys-out the "move-up" button, and this seems to be in (more-or-less "perfect": I didn't try it all out though...) coherence with the "Fixed" column in the above-mentioned "layout" table... (as to the meaning of "Fixed" in there, I can only make assumptions, of course...)

(Also, when in the dialog, I can not de-select the -5 attrib, i.e. clicking into the selection-box for it does nothing, the "X" in there remains...)

Thus, it seems evident that UR wants to PREVENT the disappearance of the -5 item attribute from position 1 within the child/search-results pane, and that seems to be independent of the sort-order - since when, by the respective UR dialog, I can't put any other attribute in position 1.

But then, obviously, I "succeeded" in "getting other attribs" into that - deemingly "secured" - position 1, by "select-n-move" (or whatever it's called: i.e. with the mouse), and whilst that might have really "succeeded" whilst the pane was within UR's main window, it created HAVOC when I did - might have done, seemingly: since I only "tried" the floating window lately, and only got into problems lately - that "select-and-move", within the FLOATED pane - this is just an assumption.

In other words: By using my mouse, I "succeeded" in getting "something else" into position 1, instead of - "Fixed"?! - attrib -5 in there... and then, within the "Layout" table, that (seemingly unforeseen, by UR's code?) "success from the outside" - i.e. from mouse use within the (allegedly) floated control (creating its own, additional UR window, by the control('s) creation), instead of using the dialog, WHICH WOULD HAVE PREVENTED THAT - within the "Layout" table then, that unforeseen change of "anything else than -5 here in position 1, only", then, simply, "FIXED" that "anything else" in that position:

In other words again: "Since this "something else than just -5 allowed" had now taken the "-5 position", it's now become "FIXED", as just the "-5" (or for templates, -8) should have been "fixed" - and that's why I'm unable to even de-select (see above for: click into the selection-box does nothing, as it would have done nothing for the "original" -5...) my "lineage" entry in position 1...

And in other words again: In somewhat "process" - strictly within UR, NONE-by-SQL, I'm positive! - I "succeeded" in replacing -5, in its "reserved", "FIXED" position 1, by something else, i.e. by "attrib 20 = lineage" here, and now "20" is fixed, instead of "-5", it's as simple as that:

Somewhere in your code, you - understandably! I'm not criticizing here, just analyzing-and-making-assumptions! - hadn't FULLY foreseen "select-n-move" as an alternative to the "Select columns" dialog: with the latter only, any "real changes" are possible, but (just seemingly) simple "rearrangements" of the columns 'already there'", being available by mouse, too, then are "successful", overriding your "Fixed" "-5 protection", if I may say so...

And at the end of the day, two questions arise:

- why hadn't fellow UR users, in (allegedly) many years of UR use (in some cases), stumbled upon this problem, before I did, after 20 months?

- "how come" that, per db (!), there is just ONE "layout" table, together with, among other things, the column widths, when there are, per UR installation (!), THREE "layouts", i.e. pane set-ups, considering every one of those might need its own column widths, if not other setting adjustments, too? But that may be my ignorance here; I admit I have not yet analyzed the UR xml files as well...

Since over those 20 months, I have created real havoc with, and by, multiplying the - thousands! - of - TOTALLY unnecessary! - entries within my respective DB's "layout" tables, I'm currently devising the necessary SQL code for recreating all those "layout" tables, for all my DBs, or, more precisely, just ONE such table, which I can then copy to anyone of my about 10 DBs - it's all about "inheritance", obviously, and I'll first have to analyze UR DB's inheritance scheme further; it's obvious that, for a start, I should leave-alone anything-special below itemID 1026, and should differentiate between "Child Items" (albeit I've never used them anyway, up to now), and "Search Results", obviously: renewing template 8 (i.e. the latter) by -5, then 20 (lineage, sort1), then 45 (tree order, sort 2), while deleting all records beyond ItemID 1025 in that table, then discovering the intermediate result(s) (working on db copies, of course...).

And so much for my - very instructive: so I'm not complaining here! - Sunday... ;-)

(When, then, everything works fine, I'll try out alternative "layouts", even with - i.e. FOR - a "floating" search results pane, in its own, dedicated UR window, again, and with looking into, and comparing, their respective XML's...)

[kinook]

The LayoutX.dat files in

%APPDATA%\Roaming\Kinook Software\Ultra Recall

holds the pane layout info of the UR window (View | Layout on the menu).

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


And the LayoutAttribute in the .urd file is used to store the configuration of the columns in the Related Items pane. But there is (normally) nothing that would require the first column to be Item Title, whether rearranging via the mouse (drag/drop) or keyboard (Item | Show Columns, Move Up/Down), or that would prevent removing Item Title as a column. Now, it does appear to be a bug that F2 still edits, but in reality it will update the item title even if a different column is showing first.

If you could send your .urd file (or a pared down version of it that still demonstrates the issue) and the other items mentioned in the previous link, it would help when investigating the issue.

[Spliff]

As I said in my previous post, the renaming just shows the problem but which lies elsewhere. In fact, it seems that drag-n-drop (!) of the columns, within the search results pane, has created multiple problems within the aforementioned (db-specific) layout table, where very obviously, the field entries do NOT correspond any more to what I see then as results; or in other terms: Whilst using the "choose columns" dialog correctly syncs with the layout table (and prevents any other column than Item Title in position 1, the same is not true for drag-n-drop column rearrangements (perhaps just because with that, I had systematically placed lineage in position 1, without getting aware that this was "not allowed", i.e. I didn't do that "manually, with the mouse", in order to override the dialog's "interdiction" to do so, but inadvertently thought everything was ok, using the dialog just for adding additional columns, or hiding ones not needed anymore).

Thus, in all my DBs, there is not only heavy de-sync between table and appearance, but also, that "Fixed" 1/0 has become quite aleatoric, and sort asc/desc 1/-1 have very often become 1,0/-1,0, and there is a chaotic mix of Null values (which seem to be original) and 0 values (which seem to have often replaced the correct Nulls) - all this in my "layout" tables.

All this is not really a problem anymore, it's just become quite some work, but since it's possible to copy (now corrected) "searches" from one db to another (similar for "child items'" list displays, and to delete unwanted residuals, it all has become quite easily doable - of course, user having created havoc in their layout table(s) are well advised to use any free, graphical SQLite frontend (allowing even manual, "in-line" corrections, just like as in an Excel table), instead of trying to do it (right then?) with the SQLite command line tool.

(Btw, Compact-n-repair will NOT resolve, or even just allege, the more or less "ruined" layout table problem(s).)

Obviously, those problems of mine had persisted for quite some time, and quite probably, some problems of mine I had described here in the months before, had been caused by this one, which I hadn't identified before, and obviously the "pane floating" has nothing to do with all that either, it just brought the deeper problem to my eyes: I had "floated" the pane, in order to (again) do (after a long time, so there was enough time for these problems to aggregate in-between), in bulk, title renames - obviously, I hadn't tried that in-between, so hadn't got aware of the (now really "old") problem (with all panes always "in place", i.e. in UR's main window together) in-between.

Also, "the above" "explains" for me why UR re-installs hadn't resolved my previous problems: no wonder when the (all!) faulty layout tables created them!

And - the user has to bear that in mind in general - as I said / implied before, it's a little bit "problematic" that the sizing (!) of the list fields is determined by the layout table, too, since with any rearrangement of the panes (floating or not), the needed column sizes (i.e. their widths) will more or less change, too; thus, any pane rearrangement (as I had done/tried for the search-results) should be done by "UR layout change", and then, the adequate column widths should be determined by that layout (i.e. probably by the xml, haven't looked into it); instead of them being retrieved by the layout table, for the user adjusting them then manually (and risking, possibly fault-creating, drag-n-drops, too: it might be though that all the problems just arose from my not leaving Item Title's fixed pos 1 alone, and that any other drag-n-drop worked correctly) - and then, back again in the "original" layout, again the widths are all wrong; all the more so since such layout changes are often made, as in my use case described above, especially FOR having (quite) different columns widths.

And the same is true for simple broadenings, e.g. of the data data explorer or similar (as said, in my set-up on the left, 1/3 of UR's total half-width of the 2600pix screen, whilst UR's 2/3 on the right, for content, and for search results in case): Sometimes I need the tree broadened, and then, whilst the content field just changes its window wrap, i.e. remains perfectly readable (possible use of tables in there would change that pic, though, but should remain an exception even for people who use such "inline" tables, here and there), the search results (or child items' list) will not adapt in any way, and e.g. since it's obviously, and currently, necessary (!) to have the Item Title column in pos 1, the lineage (e.g., and others) will more or less disappear from view.

I understand though that perfect layout management code would need not really complicated, but quite extensive code.

As it is now, I do not really understand why also Item Title's position (!) should be fixed (while understanding that renaming pos 1" is, but only so (little!) much, "easier" than "rename the title field, on any position" - and as you tell us, the "rename" even does exactly that (I hadn't tried that), it's just the "graphics" that don't follow... -, but at the end of the day, it just seems to be necessary to "fix" -8 (or then -8 or similar), preventing its deletion from the visual output, not also to fix it in pos 1 in there, and then, any drag-n-drop couldn't do any harm anymore! ;-)

Thus, this thread's original title is really as mistaken as it gets; perhaps, "Columns' drag-and-drop in Child Items / Search Results can currently create severe problems" would be a more adequate one indeed.

Btw, I understand the "fix", e.g. the column shows the non-editable title -5 (i.e. not the editable Item Title version...), whilst the user edits it though, so there's obviously some more code behind - it's just the position which creates the problems, and that seems to me to be the dispensable part of the code's restrictions.