|
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.)
|