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

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