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