View Single Post
  #2  
Old 11-11-2022, 02:41 AM
Spliff Spliff is offline
Registered User
 
Join Date: 04-07-2021
Posts: 192
Additional question: Would it be possible, or could it become possible with an update, to access the lineage attribute?

In fact, writing (in AutoHotkey again) my own open_file, goto_file, goto_previous_file dialogs, all of them maintaining (and updating) external system variables current_ur_file and previous_ur_file, AND using the Database Toolbar just as an indicator which files are loaded, and which one is the active one - I'll have to learn to not use the mouse anymore to change the current db since that wouldn't update the above-mentioned variables, and I intercept F6 and Shift-F6, the invariable (! i.e. after trying to remove those shortcuts, they reappear, just like some other UR shortcuts do), in order to not use them either, since there again, the variables would not be updated -, I am now able to technically (and not only visually) know the current db name (and, as said, the previous one); thus, I've been able to do what I originally had in mind, with the caption now just displaying the current item title, and the macro part then displaying the respective file system folder in any of my file managers also works as expected now.

On the other hand, I had not envisioned the whole spectrum of the task, yesterday, since the above just works for 1 and 2 levels: in UR, db name (which is also replicated (by me) in the db's source item's title), or that one plus first-level UR "folder" entry, and in the file system, in ("fixed") drive d:\, the "main" folder, or that one plus the parent folder... of further-down folders that is, just the same as in UR, those first-level tree entries are just parent items to further-down "folder" entries. (And so on, in case, with a "folder" hierarchy further down.)

That way, I need the "lineage" information, too, in order for my macro knowing the respective file system hierarchy, for displaying further-down NTFS folders.

Since currently, this UR info does not seem to be readily available, except by a column in the Child Items pane, by first going to the parent (!) of the "folder" item, then "copy grid values", I instead wrote the necessary code to "go up" in the tree itself, retrieve the respective info from the caption then (with the necessary wait times in-between, without which it's not reliable), and finally go back to the "folder" item for which I have been gathering the necessary path ("lineage") info that way.

This works indeed but is visually "crazy" and takes, according to the "indentation level" (I wrote it for up to 4, which seems reasonable for a start), several seconds each time, just for the information gathering, whilst the display of the respective NTFS folder, once the path information is there, is immediate (i.e. less than half a second).

Hence my request to make really available much more standard information by way of the Attributes Pane (not: Child Items pane), and that is, in identifiable fields from which then ^c is possible, even without a previous F2 (which for "lineage" information would not be possible anyway, since that's non-editable info).

Since the above would be quite some coding, I'd suggest just 1, 2 or 3 such fields, but for which the user would be able to assign the attribute of their choice, i.e. some field allowing quick ^c, with a drop-down for selecting any of the usual attributes to by displayed in it; this would be much less coding on your side, and would allow the user to automate UR's interaction with other application much more than it's possible today. (See MS Word, MS Excel, or then MindJet

At the end of the day, it's also been the fact that MS Word / Excel, and also MindJet / MindManager for example, which all allow some programmatical interaction with, and external use of, their data, so that for any of these professional applications, both some add-ons are available, and more technical users are able to get data for further use out, without visually jumping around on the screen being necessary, as described for my "display the respective file system folder" macro above.

I'm not speaking of an API, albeit that would have been optimal, but just of better access of obviously already available data, to the clipboard.


EDIT: I'm aware of UR's file system sync feature, but I don't want to clutter my UR DBs with quickly outdated file system data, considering that any such sync system comes with de-sync problems. From my experience - other users may have different experience though -, my "standard" folders, both in UR and in the file system, don't change often (and when they change, I have to manually adjust them "on the other side" indeed), but their content (incl. new or renamed folders at deeper-down levels) changes a lot, so I prefer the parallel view between UR and file manager, instead of a mix-up, but as described above, the necessary path info, on UR side, is currently very unwieldy to get, hence my request for considering an amendment.

And, such an additional "field" could be in the form of an additional "bar" (visible by toggle), just below the menu-and-toolbars, and could come with a drop-down menu for the "attribute" it should display (and which would be retrievable from there, by ^c when it has focus).

And it could even be editable, according to its current (editable or not) content, not only for a compound search string (!), but also as a quick(er) search interface, even for tree filtering and the like: some "quick access" to a multitude of functions... just dreaming...


EDIT 2 - SIMPLE SOLUTION (EDITED and corrected with regards to the now unique separator character): I had totally forgotten the command "Copy item command line"; we can copy the current file name from there: "ur://d:/UR/0.db?item=", i.e. the substring between the "//" and the ".db?item=". (or ".urd" in case, of course)

I had forgotten it because it unfortunately does neither make available the item title (retrievable from the caption though, as explained above) nor the "lineage",

BUT: it's obvious that a SECOND such command, in the Item menu, would resolve the current problem:
item's_file_path¬item's¬lineage¬lineage¬etc

The FIRST lineage element would be the source item's title (which thus could be different from the file name), and the LAST lineage element would then be the item title, and chars like "/" and "|" would be preserved for further use in item titles, since in this syntax, the very first "¬" would separate the file path from the lineage, and every further "¬" would then separate the lineage elements between themselves.

(This command would be in part redundant to the currently-available one, but it would be important to have BOTH info, file-path AND lineage-with-item-title, within the same clipboard dump, in order to avoid juggling around with several clipboard entries then.)

The necessary code work, in order to realize this command, would be MINIMAL, and I would be happy to publish my resulting (complete) scriptlet (incl. sub-string retrievals and creation of a new file system folder, after asking dialog, when the respective folder doesn't yet exist, etc) here.

Last edited by Spliff; 11-11-2022 at 04:42 AM.
Reply With Quote