Spliff
11-26-2022, 04:43 PM
The recent thread "Synchronizing custom item templates between different DB files" shows the problems again, but doesn't resolve its basics.
Kyle, I had been literally enchanted by your very constructive - and incredibly speedy! - reaction a fortnite ago, and in a day, I had written the basics of the AutoHotkey display-the-filesystem-folder, function, then wanted it to make as perfect as possible, also triggering the icon switch to "folder" (see below), and I'm stuck again in the, excuse me, total chaos in UR's column ("attributes") management, chaos at least from that users' perspective who are unable to understand your help file bits on the matter (even after reading every single bit 5 times...).
As an aside here, could you make available the variable %ICON%, too, within your "command line" clipboard output? Not necessarily as text, the ID number would suffice, we then could retrieve the current icon number, and check if it's already "folder" (or something else, for other means), then react accordingly; ditto for other attributes: I'm sure with such reading access, we will find good use cases for many of them!
Now for this absolutely awful "attributes" mess, please correct my errors, and comment on my non-understandings:
a)
Tools - Attributes:
Here, most are checked as "System", even when the category is not "System", and the user can not check or uncheck anything, of those which are there (the user can add additional ones, though, which I have not done).
I understand this is for defining fixed values, dropdown menu values, etc. (which then will appear in the "Value" fields of the Item Attributes Pane) (I have not done that)
b)
Tools - Options - Attributes - System Attributes to display: I have ALL checked (=27) and clicked on "Apply", i.e.
Access Count
Compressed Size
Content-Type
Date Accessed
Date Created
Date Modified
Default Child Template
Doc Type
Document Size
Encoding
Flag
Has Children
Icon
Indent Level
Item Count
Item Notes
Item Title
ItemID
Keyword Count
Keywords (user-defined)
Lineage
Object Exists
Parent Count
Pending Reminder
Sync Date
Template Item
Tree Order
I understand these are the system attribs "available", i.e. available for the (e.g. "Text") templates (I here speak exclusively for those "Text" templates and items, since I don't use any other, except for 1 "Inbox" and several "Searches").
What that "availability" means, I don't really understand though, see below, but let's say here that if a system attrib is not checked (anymore) in this list, it will not be "available" in the components described below, OR probably not in NEW items created after that setting change (and since a) and b) are in the program, not in the db, they will probably work for ALL (even existent?) DBs?)...
(Availability in c) Text-Template (and other templates); in d) Attributes Pane; in e) Child Items Pane? see below)
c)
Let's try to go top-down, so now we have to consider the "Text"-Template. I would expect that all 27 attribs from b) now appear in the Attributes Pane d) of the Text template, but that is not the case, in fact there might be 17 out of 27, but that number of 17 seems to change, too...
For example, in the Item Attributes Pane d), I have (all system, abc):
Access Count
Date Accessed
Date Created
Date Modified
Default Child Template
Flag
Has Children
Icon
Item Title
ItemID
Keyword Count
Parent Count
Template Item
whilst in the text template c), I have 5 more:
+ Form
+ Item Count
+ Primary Attribute
+ Template Name
+ Title Expression
and 1 less:
- Template Item
(=17 out of 27, but obviously aleatoric)
Now I might have "fiddled around" with settings before, so I understand that for existent items, I will not get predictable results (which is catastrophic in its own right, see below), but I would expect that for items created new, with the new settings in the list b), and thus with the new availability of ALL attribs for c), I would get predictable results in d), but that's not the case either, as explained.
e)
Finally, in the Child Items Pane (^3), I have just some attribs, by (context menu or F9) "Choose Columns", and here I understand these are individual to the item from which these columns were chosen, so this creates perfect chaos in its own right, since to begin with, I should never have fiddled around with those settings (I want to be global for the db) when an individual item was on display, but I should have done these e) settings exclusively for c)... which would not have resolved the base problem, since there again, any settings' change, even for the template, would been applied just for newly created items (with that template), not also for the existent ones...
Thus, e) is a problem on its own, similar to venerable, long defunct askSam's "field" creation problem: any change to the template just applied to the then-created new items, and thus, any search for / filtering by field values gave aleatoric results, those fields not necessarily being present, or equally named, in items created before the the template change...
But my main problem is between c) and d), especially since the list b) (even when all 27 are checked, as said) is not automatically displayed in d) for the template, and thus not in d) for the items created from that template either: not even the new ones, let alone the old ones.
f)
My problem is NORMALIZATION of that Item Attributes Pane d), since if we want to interact with the attribs in that pane, by macro / scripting, it HAS to be normalized, why?
Because it's not possible, in that pane, to use shortcuts to go to specific attribs, thus entering an "i" in that pane will NOT go to "Icon" (and, of course, "it" will not go to "Item Title", instead of going to "Icon", retrieving just the very first character), no: after any such input, the focus will stay onto the very first attrib, "Icon Count", but replace the icon count value by "i" or whatever, i.e. will create a total mess.
Thus, any macro, any script will need to KNOW the POSITION of the attrib which is to be changed, and then, the rest is easy, since the position can be reached by {home} = go to first attrib, then {down n} for going down n-1 times to reach attrib at position n, and then, F2 or a simple {right} will go to the value column, then again {home}, and here then, for attrib Icon, an "f" will go to "File" ("fi" or "fo" will not work as expected), and then, some {down} or {down 2} (if there is some intermediate value in-between) will finally go to "Folder" value, and {enter} will finalize this, whilst ^1 goes (back) to the tree: the values of the attrib "Icon" are in a fixed list, so there (where you can also navigate, to some degree at least, with entering (single) chars (only), you know where to go, NOT so for the attrib list where the position of your target attrib is not determined, nor is there any "shortcut" by entering (single) chars (which for many attribs would not even help...).
In other words, if it's not possible to normalize the Item Attributes Pane, at least within a given db, AND for existing AND new items (or one kind = template, here "Text"), it's impossible to run a macro / scriptlet for switching /setting any given attrib value, since the macro would run, without identifying its target, and then creating havoc.
Thus, I tried to identify the attribs / attrib list displays within SQLite (Navicat again), and I had to "discover" that they weren't anywhere to be found, I checked the tables, the views... and the table ItemAttribute for example just listed the Icon, and Title attributes (even when the icon attrib was default, but nothing else; I especially missed a crosstable listing the Item Attributes List attribs lists for every item, or then for "sets" of items, i.e. for groups of items for which the attribs (not: values) displayed were identical.
So I'm at a complete loss here, and of course, it would be possible, technically, to deploy sqlite.exe in order to retrieve, and even re-set the icon (or any other) values (since we've got the item IDs from the "command line" clipboard output, but... obviously, this would not be realistic within a scriptlet, deemed to run within a second of the user's time.
As explained above, your attributes management, especially your management of the display / availability of the different attributes within the components described above is a black box for me; my so-called "user experience" with that, important, part of the program is absolutely awful, and I apply hours and hours upon this.
80 p.c. of askSam's user forum's threads concerned templates and fields, and those problems had never been addressed, technically, just endless mumbo-jumbo around those problems, year after year, within said forum (defunct, too)...
On the other hand, MyInfo (in versions 4, 5, 6; I don't know about current v. 7, reprogrammed allegedly from scratch) did it the simple way, developer-wise and user-wise: just one attributes set per db, and any change / addition to that set then applied to any item, previously created, or new, and the overwhelming majority of users were very happy with that concept, the 2, 3 again an again complaining about the missing ability to set the columns for each item individually, albeit asked, never explained why they didn't want to set up a different db for different column needs, which was all the less understandable since MI (at the time, as said I don't know about current state of affairs) provided "global search" even beyond db boundaries...
I'm not advocating to cripple UR, but I very much hope there could be some explanation how to overcome the described problems, as a first measure (for example, it is said that we can search for all = *, then add attribs, by context menu within the Item Attributes Pane, and it might even be possible to delete some of the attribs in there as well, that way, deleting just the DISPLAY of course, not the values... but as explained above, even NEW items then will display unexpected attribs and/or will hide some, unexpectedly: As explained, even with a changed template, the new items will not correspond to the template, so it's a black box indeed, so any big rehaul, before a better understanding what's going on, would not be the very best idea the user might have...
(And I have read all "attributes"-related forum threads, too, to no effect...)
Of course, after "mastering" the Item Attributes Pane (IAP), and thus being able to write a reliable (!) scriptlet to change the icon, in it, I'll invariably come up with the "demand" for some "input bar", in order to AVOID that jumping around within the IAP, and please let me remind us that the necessary process code for the commands in such a "command bar" (displayed just optionally, of course) already exists, since whenever we finally succeeded to change a value in the jungle of the IAP's aleatoric attrib lists, internal UR code, even today, then triggers the respective SQLite updates, so very few additional code would be needed for implementing such a bar, and ideally we could even add several such commands in a row, in the form attribname=value; anotherattribname=value; etc., and that would just demand a tiny loop on top, run then just once if there's no semicolon in the bar's input...
For the time being, I discovered that in order for macros within the IAP being able to run, it's sufficient that we just display ONE attrib (line) on the screen, i.e. we can quite "minimize" that pane, since once at least one attrib is displayed, the control then does an automatic vertical scroll as necessary, then changes the value, whatever the attrib is, "on vue" in that single visible row.
At the condition then that we got the right attrib, and if not, we create havoc, and thus it's necessary to normalize the attrib list to be displayed... hence my (unsuccessful) try to simple display ALL 27 system attributes from the list a) above... and then, in case, if the respective user also uses "user attributes", they might not do an alphabetic list in there anymore, but set it to "by category", thus their user attributes coming AFTER the system attribs, and this way, they could maintain the normalization of the system attribs list at least; any change to the list will obviously have totally unexpected results, and since we can't foresee our, tomorrow's needs, it seems advisable to simply display ALL system attribs, then just display one row (and the caption) of the pane, in order for the then very long (but invariable!!!) list not cluttering your screen.
Kyle, I had been literally enchanted by your very constructive - and incredibly speedy! - reaction a fortnite ago, and in a day, I had written the basics of the AutoHotkey display-the-filesystem-folder, function, then wanted it to make as perfect as possible, also triggering the icon switch to "folder" (see below), and I'm stuck again in the, excuse me, total chaos in UR's column ("attributes") management, chaos at least from that users' perspective who are unable to understand your help file bits on the matter (even after reading every single bit 5 times...).
As an aside here, could you make available the variable %ICON%, too, within your "command line" clipboard output? Not necessarily as text, the ID number would suffice, we then could retrieve the current icon number, and check if it's already "folder" (or something else, for other means), then react accordingly; ditto for other attributes: I'm sure with such reading access, we will find good use cases for many of them!
Now for this absolutely awful "attributes" mess, please correct my errors, and comment on my non-understandings:
a)
Tools - Attributes:
Here, most are checked as "System", even when the category is not "System", and the user can not check or uncheck anything, of those which are there (the user can add additional ones, though, which I have not done).
I understand this is for defining fixed values, dropdown menu values, etc. (which then will appear in the "Value" fields of the Item Attributes Pane) (I have not done that)
b)
Tools - Options - Attributes - System Attributes to display: I have ALL checked (=27) and clicked on "Apply", i.e.
Access Count
Compressed Size
Content-Type
Date Accessed
Date Created
Date Modified
Default Child Template
Doc Type
Document Size
Encoding
Flag
Has Children
Icon
Indent Level
Item Count
Item Notes
Item Title
ItemID
Keyword Count
Keywords (user-defined)
Lineage
Object Exists
Parent Count
Pending Reminder
Sync Date
Template Item
Tree Order
I understand these are the system attribs "available", i.e. available for the (e.g. "Text") templates (I here speak exclusively for those "Text" templates and items, since I don't use any other, except for 1 "Inbox" and several "Searches").
What that "availability" means, I don't really understand though, see below, but let's say here that if a system attrib is not checked (anymore) in this list, it will not be "available" in the components described below, OR probably not in NEW items created after that setting change (and since a) and b) are in the program, not in the db, they will probably work for ALL (even existent?) DBs?)...
(Availability in c) Text-Template (and other templates); in d) Attributes Pane; in e) Child Items Pane? see below)
c)
Let's try to go top-down, so now we have to consider the "Text"-Template. I would expect that all 27 attribs from b) now appear in the Attributes Pane d) of the Text template, but that is not the case, in fact there might be 17 out of 27, but that number of 17 seems to change, too...
For example, in the Item Attributes Pane d), I have (all system, abc):
Access Count
Date Accessed
Date Created
Date Modified
Default Child Template
Flag
Has Children
Icon
Item Title
ItemID
Keyword Count
Parent Count
Template Item
whilst in the text template c), I have 5 more:
+ Form
+ Item Count
+ Primary Attribute
+ Template Name
+ Title Expression
and 1 less:
- Template Item
(=17 out of 27, but obviously aleatoric)
Now I might have "fiddled around" with settings before, so I understand that for existent items, I will not get predictable results (which is catastrophic in its own right, see below), but I would expect that for items created new, with the new settings in the list b), and thus with the new availability of ALL attribs for c), I would get predictable results in d), but that's not the case either, as explained.
e)
Finally, in the Child Items Pane (^3), I have just some attribs, by (context menu or F9) "Choose Columns", and here I understand these are individual to the item from which these columns were chosen, so this creates perfect chaos in its own right, since to begin with, I should never have fiddled around with those settings (I want to be global for the db) when an individual item was on display, but I should have done these e) settings exclusively for c)... which would not have resolved the base problem, since there again, any settings' change, even for the template, would been applied just for newly created items (with that template), not also for the existent ones...
Thus, e) is a problem on its own, similar to venerable, long defunct askSam's "field" creation problem: any change to the template just applied to the then-created new items, and thus, any search for / filtering by field values gave aleatoric results, those fields not necessarily being present, or equally named, in items created before the the template change...
But my main problem is between c) and d), especially since the list b) (even when all 27 are checked, as said) is not automatically displayed in d) for the template, and thus not in d) for the items created from that template either: not even the new ones, let alone the old ones.
f)
My problem is NORMALIZATION of that Item Attributes Pane d), since if we want to interact with the attribs in that pane, by macro / scripting, it HAS to be normalized, why?
Because it's not possible, in that pane, to use shortcuts to go to specific attribs, thus entering an "i" in that pane will NOT go to "Icon" (and, of course, "it" will not go to "Item Title", instead of going to "Icon", retrieving just the very first character), no: after any such input, the focus will stay onto the very first attrib, "Icon Count", but replace the icon count value by "i" or whatever, i.e. will create a total mess.
Thus, any macro, any script will need to KNOW the POSITION of the attrib which is to be changed, and then, the rest is easy, since the position can be reached by {home} = go to first attrib, then {down n} for going down n-1 times to reach attrib at position n, and then, F2 or a simple {right} will go to the value column, then again {home}, and here then, for attrib Icon, an "f" will go to "File" ("fi" or "fo" will not work as expected), and then, some {down} or {down 2} (if there is some intermediate value in-between) will finally go to "Folder" value, and {enter} will finalize this, whilst ^1 goes (back) to the tree: the values of the attrib "Icon" are in a fixed list, so there (where you can also navigate, to some degree at least, with entering (single) chars (only), you know where to go, NOT so for the attrib list where the position of your target attrib is not determined, nor is there any "shortcut" by entering (single) chars (which for many attribs would not even help...).
In other words, if it's not possible to normalize the Item Attributes Pane, at least within a given db, AND for existing AND new items (or one kind = template, here "Text"), it's impossible to run a macro / scriptlet for switching /setting any given attrib value, since the macro would run, without identifying its target, and then creating havoc.
Thus, I tried to identify the attribs / attrib list displays within SQLite (Navicat again), and I had to "discover" that they weren't anywhere to be found, I checked the tables, the views... and the table ItemAttribute for example just listed the Icon, and Title attributes (even when the icon attrib was default, but nothing else; I especially missed a crosstable listing the Item Attributes List attribs lists for every item, or then for "sets" of items, i.e. for groups of items for which the attribs (not: values) displayed were identical.
So I'm at a complete loss here, and of course, it would be possible, technically, to deploy sqlite.exe in order to retrieve, and even re-set the icon (or any other) values (since we've got the item IDs from the "command line" clipboard output, but... obviously, this would not be realistic within a scriptlet, deemed to run within a second of the user's time.
As explained above, your attributes management, especially your management of the display / availability of the different attributes within the components described above is a black box for me; my so-called "user experience" with that, important, part of the program is absolutely awful, and I apply hours and hours upon this.
80 p.c. of askSam's user forum's threads concerned templates and fields, and those problems had never been addressed, technically, just endless mumbo-jumbo around those problems, year after year, within said forum (defunct, too)...
On the other hand, MyInfo (in versions 4, 5, 6; I don't know about current v. 7, reprogrammed allegedly from scratch) did it the simple way, developer-wise and user-wise: just one attributes set per db, and any change / addition to that set then applied to any item, previously created, or new, and the overwhelming majority of users were very happy with that concept, the 2, 3 again an again complaining about the missing ability to set the columns for each item individually, albeit asked, never explained why they didn't want to set up a different db for different column needs, which was all the less understandable since MI (at the time, as said I don't know about current state of affairs) provided "global search" even beyond db boundaries...
I'm not advocating to cripple UR, but I very much hope there could be some explanation how to overcome the described problems, as a first measure (for example, it is said that we can search for all = *, then add attribs, by context menu within the Item Attributes Pane, and it might even be possible to delete some of the attribs in there as well, that way, deleting just the DISPLAY of course, not the values... but as explained above, even NEW items then will display unexpected attribs and/or will hide some, unexpectedly: As explained, even with a changed template, the new items will not correspond to the template, so it's a black box indeed, so any big rehaul, before a better understanding what's going on, would not be the very best idea the user might have...
(And I have read all "attributes"-related forum threads, too, to no effect...)
Of course, after "mastering" the Item Attributes Pane (IAP), and thus being able to write a reliable (!) scriptlet to change the icon, in it, I'll invariably come up with the "demand" for some "input bar", in order to AVOID that jumping around within the IAP, and please let me remind us that the necessary process code for the commands in such a "command bar" (displayed just optionally, of course) already exists, since whenever we finally succeeded to change a value in the jungle of the IAP's aleatoric attrib lists, internal UR code, even today, then triggers the respective SQLite updates, so very few additional code would be needed for implementing such a bar, and ideally we could even add several such commands in a row, in the form attribname=value; anotherattribname=value; etc., and that would just demand a tiny loop on top, run then just once if there's no semicolon in the bar's input...
For the time being, I discovered that in order for macros within the IAP being able to run, it's sufficient that we just display ONE attrib (line) on the screen, i.e. we can quite "minimize" that pane, since once at least one attrib is displayed, the control then does an automatic vertical scroll as necessary, then changes the value, whatever the attrib is, "on vue" in that single visible row.
At the condition then that we got the right attrib, and if not, we create havoc, and thus it's necessary to normalize the attrib list to be displayed... hence my (unsuccessful) try to simple display ALL 27 system attributes from the list a) above... and then, in case, if the respective user also uses "user attributes", they might not do an alphabetic list in there anymore, but set it to "by category", thus their user attributes coming AFTER the system attribs, and this way, they could maintain the normalization of the system attribs list at least; any change to the list will obviously have totally unexpected results, and since we can't foresee our, tomorrow's needs, it seems advisable to simply display ALL system attribs, then just display one row (and the caption) of the pane, in order for the then very long (but invariable!!!) list not cluttering your screen.