Hoist / New Tab: possible in combination?

[Spliff]

These commands, in combination, are more than welcome, but I have problems with its current implementation. I looked into the help, and it seems that there is currently no other way than to do it this way, having a database "A" with source item "A", and with a subtree "Sub" I then want to work upon in a new tab:

I have one tab (for database "A"), of which the denomination changes with the current item (since I did not "lock title").

I am on item "Sub". If I do "Hoist", the hoisting is done within the current tab, which is not wanted in the use case I have in mind - of course, a simple command "Hoist", for hoisting into the current tab, should be preserved, for other use cases.

So I do "New Tab" instead, in order to hoist "Sub" on a SECOND tab.

This opens a new tab "Sub" (which is not hoisted yet of course) as FIRST tab, while my original tab becomes tab "A" on SECOND position, which is not wanted: I would like to have the "original" tab with the "original database view", and then more tabs, on 2nd, 3rd... position, with "special versions" of that: FROM "general" TO "specific". So in order to rectify the (for me, and logically) "wrong" order, I must move one of the tabs with the mouse.

(Here, I also get a dialog "Unknown File - File Identifier - By FileInfo.com - Search FileInfo.com ... / Use the default Windows service - OK" (I must then manually close this dialog): this is very probably a problem of my system and has nothing to do with UR, but I get this message only in this situation, not also for example when I create new UR databases or in other situations. Any idea about that?)

Then, from the "Sub" item in the newly created "Sub" tab, I do "Hoist", and then only I get the "Sub" subtree hoisted in its own, "secondary" tab.

A "natural way" to do this would be to trigger a command "Hoist in/to new tab", and which would create a second tab (to the right of the current tab) in which the currently selected item / subtree would appear hoisted.

Could you please consider implementing this "combined" command?

(Or did I overlook how it can be done, currently?)

[kinook]

...So I do "New Tab" instead, in order to hoist "Sub" on a SECOND tab.

This opens a new tab "Sub" (which is not hoisted yet of course) as FIRST tab, while my original tab becomes tab "A" on SECOND position, which is not wanted: I would like to have the "original" tab with the "original database view", and then more tabs, on 2nd, 3rd... position, with "special versions" of that: FROM "general" TO "specific". So in order to rectify the (for me, and logically) "wrong" order, I must move one of the tabs with the mouse.

I wasn't able to reproduce this behavior. Item Tab | New Tab or right-click -> Open in New Tab always creates a new tab to the right of other existing tabs. Then Tree | Hoist or Ctrl+Shift+H will hoist the tab. We can consider adding an option to hoist when opening a new tab.

(Here, I also get a dialog "Unknown File - File Identifier - By FileInfo.com - Search FileInfo.com ... / Use the default Windows service - OK" (I must then manually close this dialog): this is very probably a problem of my system and has nothing to do with UR, but I get this message only in this situation, not also for example when I create new UR databases or in other situations. Any idea about that?)
I wasn't able to reproduce this either.

[Spliff]

Thank you very much, Kyle, for your speedy reply!

As said / implied in my parenthetical, the "Unknown File - File Identifier - By FileInfo.com - Search FileInfo.com" problem would be a problem of my system; I obviously should delete that third-party "service".

As for Rightclick - "Open in new tab", you are absolutely right, that will be done to the RIGHT of the current tab, and I obviously should try to assign a shortkey to that, the second step then being the "Hoist" command - thank you very much for considering to make available this within a single command "Hoist within a new tab"!

Currently, I'm not sure how I could assign a shortcut to an UR context-menu; I'll have to look into this.

As for your "Item Tab | New Tab or right-click -> Open in New Tab always creates a new tab to the right of other existing tabs.", this is a misunderstanding, sorry for not having been perfectly explicit above:

You are right indeed with what you say, but that new tab, created to the right of the existing tab, is NOT a tab with the currently-selected item being the "current" item in there, but with the SOURCE tab of the current tab being selected, thus my "critique" that that second tab, to the right, now having become the "original tree", whilst the original tab, the one to the LEFT, stays at the "current item" indeed, so the order of the "original tree" and the "special sub-tree, to then be hoisted, within the next step", has become the first tab of the two, thus my need to then switch the positions between the tabs 1 and 2 (but I could do this also with the keyboard, not only with the mouse, as I had only mentioned above).

(The other alternative would have been to manually go back to the source item in (new/old) tab 1, and to manually go to the item (= already selected as "current item" in tab 1) to be hoisted in (new) tab 2; obviously, currently, switching the two tabs (by keyboard shortcuts) is faster by far, since then, both "current items" are already "there", i.e. correctly positioned/selected, both in tab/tree 1 (the "original" one, after the switch) and in tab/subtree 2 (the one then to be "hoisted").

It's obvious that a command "Hoist current item in new tab" would come enormously handy, thus thank you very much again for your considering it!

[Spliff]

Re the above-mentioned "Unknown File - File Identifier - By FileInfo.com - Search FileInfo.com" problem:

Web research https://windowsfileviewer.com/file_identifier showed that that tool had been installed together with "File Viewer Lite", which I use perhaps once a year and which is free.

So I de-installed this "File Identifier" tool (without problem, and "File Viewer Lite" is legitimate, too), then tried again, in UR, "New Tab" - the problems have nothing to do with a shortkey which may interfere (^t here, and which may trigger something outside UR) since I use the menu: "Tab - New Tab".

Now that the "File Identifier" tool is gone, I get, in the very same situation, i.e. by "Tab - New Tab", the original Windows file dialog (!): "You'll need a new app to open this about link - Look for an app in the Microsoft Store - [checkbox automaticatlly checked:] Always use this app" btut with the "OK" button greyed out, so here, I have to click on "Look for an app in the Microsoft Store" in order to get rid of the dialog (it opens another MS window telling me there is no application for this, and then I can manually close that second MS window - EDIT for clarification: this second MS window is "Microsoft Store - Results for 'about' - No results for this filtering" - no idea what this "about" may be, but this detail probably helps?), whilst with the proprietary "File Identifier" tool, I was at least able to close that first dialog already.

I did NOT get into this situation when by the context menu in the tree ("Data Explorer"), I do "Open in new tab", this worked as expected.

Then, I tried, again by context menu, "Open document", and here, the item was opened in my rtf tool (which in my case is Atlantis Word Processor, I don't use MS Word 2016 but very exceptionally), and further tries with "Open document" brought "Click here to continue editing stored content externally / Click here to resume internal editing".

I never use external editing though, normally (except for trying this out now).

From the above, I deduct that perhaps the file dialogs (be them the proprietary tool or then the "original" MS Windows dialog) when I do "Tab - New Tab" MAY be connected with UR's functionality to allow for external editing, and this alternative MAY be triggered by "Tab - New Tab", and then the Windows system does obviously NOT know what to do, externally, with an UR tab = a whole tree within the running UR application window?

MORE EDITS:

- No macro tool or similar running which could cause this.

- The "point of departure" for (the non-problematic) "Context menu - Open in new tab" is a SINGLE item, whilst the "point of departure" for (the problematic) "Tab - New Tab" is unspecified and thus may be processed, by the command, as "whole tree", thus probably Windows not knowing what to do with it, but Windows obviously gets the order to "have a look upon it", this "look into it" hint for Windows obviously is redundant since the processing, in ANY situation, i.e. even if the user regularly opens items = single "documents" externally, the "new tab" will necessarily be created within UR

- If the problem can NOT be identified, the way around obviously is "Open in new tab", on a single item, to create a new tab, where, as said, the problem doesn't appear

[kinook]

As for Rightclick - "Open in new tab", you are absolutely right, that will be done to the RIGHT of the current tab, and I obviously should try to assign a shortkey to that, the second step then being the "Hoist" command - thank you very much for considering to make available this within a single command "Hoist within a new tab"!

Currently, I'm not sure how I could assign a shortcut to an UR context-menu; I'll have to look into this.
At Tools | Customize | Keyboard, assign a keyboard shortcut to Category: Item, Commands: Open In New Tab.

[kinook]

Now that the "File Identifier" tool is gone, I get, in the very same situation, i.e. by "Tab - New Tab", the original Windows file dialog (!): "You'll need a new app to open this about link - Look for an app in the Microsoft Store - [checkbox automaticatlly checked:] Always use this app"
Please send or post the info from

https://www.kinook.com/Forum/showthread.php?t=3038

[Spliff]

1 - You're right, once I assign a shortkey over there, that shortkey will also appear in the context menu; my fault to expect something "special" for that, it's as simple as that.

2 - Hoping to have understood your second post correctly - you want proof? -, I took a screen video, full-screen, upon a newly-created "trial" UR database, with just 4 "trial" items of my own, and I made two tries, subsequently:
- NOT de-selecting the check-box "Always use this app"
- Then, selecting the check-box, i.e. setting it to "NO".

Both tries brought exactly what I had described above (so the problem has nothing to do with my descriptions above applying to my "regular" UR database with about 60,000 items (i.e. no "database size problem"), and I'm using Windows 10 Pro latest version (= automatic updates) and UR 6.2 latest (my check today = "You have the latest version").

The less-than-2-minutes video (my "stayings" on the "OK" button are caused by multiple tries to click onto the greyed-out button, and as said, I, in both cases, I had to clic), is almost 10 MB, and the "export" from my ".approj" format (= Active Presenter Professional) into ".mp4" took about 5 minutes (!), but the result is "working", whilst for example, a "simpler" try with (free) "FlashBack Express Recorder" just brought a black screen; there are other, paid, "screen recorders", and I should perhaps trial some of those...

I'll try now to send you the .mp4 video by mail.

This being said, "Item - Open in New Tab" and Then "Tree - Hoist" (both assignable to shortcuts) will bring, combined, the expected result for a combined command "Item - Hoist in/to New Tab" indeed.


EDITS: 10 MB not possible by my mail, so I tried 2 times with transfernow.net, first try's "transfer link" https://www.transfernow.net/dl/20210525f3B0KMTK/ptjol0Sv, second try's being https://www.transfernow.net/dl/20210525vjwNkgTd/zO22SSQe - in both cases then "This transfer doesn't exist". Can't find a working, free file sharing service. Did the video with "Active Presenter Professional", around 90 seconds, mp4 = 10 MB; did a second video with Ashampoo Snap 11, mwv file 26 MB (both full screen). WeTransfer sends a code, without any field to enter that code; SendThisFile wants me to create an "account"; MailBigFile, after confirmation, sends "50 p.c. off", with a quite hidden "Your files have been uploaded and your recipient notified by email.", so perhaps this was successful, and transfernow, NO, "hours" afterwards, sends me another mail, with https://www.transfernow.net/dl/20210525f3B0KMTK/ptjol0Sv - and again, then "This transfer doesn't exist". Thus, let's hope that MailBigFile DID sent a file, or a functioning link, and at the very least, we'll have learned, "Don't use transfernow, just much ado about nothing over there"...

[kinook]

The recording is helpful, but I need a way to reproduce this behavior. Can you also send or post items #1 and #2 from that link? Thanks.

[Spliff]

Hello, I'm happy that obviously SendBigFile (mentioned in the help page) made the recording available to you, either by sending it or by providing a link, so obviously, SendBigFile is the service to be used in these circumstances!

It's also obvious I'm the only user who has encountered this problem, so at the end of the day, it's obvious this doesn't need further attendance, and we can this shelve now, all the more so since the above-mentioned way-around avoids the problem to occur even on my system.

Just let me add that I'm very happy that the arrival of my screen video proves I did not make up this, and this obviously also applies to any other remarks of mine re UR. On the other hand, in just several weeks, I've been observing lots of "edges" which had never been addressed in this forum, so I come to the conclusion that I must be "nitpicking" or something alike? I don't know and can't say, but be assured that I try to be as constructive as it gets!

[Spliff]

I fully understand that the hoisting functionality is highly probably really complicated, so I don't know if doing something about this problem is possible, or if the coding work it demands, would make sense.

Priority should be that even with hoisting, no item / sub-tree should never be lost, and I can't say so from my observations so far, so I really admire this functionality, even as it is.

As above, given two tabs, the left one for the whole tree (database), with sub-trees A...Z, the right one hoisted to sub-tree S (for "Sub").

Now, working on the right (= hoisted) tab, I discover one or more items which don't belong in there; currently, selecting them (even a single one), cut it (^x), shift to the left tab (= full tree), navigating to sub-tree "T" (for "target", i.e. a position outside the (in the other, hoisted tab) hoisted part of the tree, doing ^v there will have NO effect, BUT when going back to the hoisted tab, the "cut out there" item thankfully is always there, it has not vanished.

Thus, for getting items / sub-tree out of hoisted parts of the tree, currently there are just two alternatives:

- gather them in some sub-tree "Export" within the hoisted tab sub-tree, then un-hoist that tab (> full-tree), then distribute those items to their respective, final destinations

- go to the tab representing the full-tree, navigate there to the item to be moved, do the necessary move over there... BUT this un-hoists the second tab, too! So there is no benefit in trying this, since any try to "get out" something out of a hoisted tree part will either be not successful or "un-hoist it all", so my first alternative seems to be the way to follow: gather those items, then un-hoist, then distribute within the full-tree, then hoist again


EDIT: "Copy" (^c, then ^v), on the other hand, works as expected, i.e. is successful on-spot, but then, what's going on "behind the scenes" for "Copy" is very different, obviously.


SECOND EDIT: Moving, in tab 1 (= full-tree) an item from outside the (in tab 2) hoisted part, INTO the hoisted part, will work AND then correctly appear also in tab 2 which (listening to the noise of my HDD), before being displayed again, obviously will be updated, i.e. UR checks the hoisted part of the full-tree for possible changes, then only displays the hoisted tab again.

Also, changes "WITHIN" (i.e. limited to) the hoisted part, be it in tab 1 or tab 2, are, when you switch to the other tab, correctly displayed over there, i.e. any change (be it in tab 1 (full) or 2 (hoisted)) will be processed in and for the full-tree (tab 1), and any switch (back) to tab 2 will "update" the hoisted part in there accordingly, whenever necessary.

So I believe to have better understood now how "hoisting" technically works - any processing is done upon the full-tree, with the hoisted part being updated whenever necessary? -, and this also seems to indicate that the moving problem described above should be resolvable quite easily? (I may be mistaken here though.)

[Spliff]

My thread "Search problems" has got 681 views up to now, for various subjects, but this thread here, "Hoist/Newtab possible in combination?" has got 432 views, for just the one subject in the title.

This clearly indicates that there is enormous, general interest in hoisting, and in hoisting being the sleekest possible (i.e. "easy-peasy").

Thus, I would like to mention here, my post of today, in "Search problems", and in which I suggest that the search in a hoisted tree (i.e. in a tab displaying a hoisted sub-tree) should, by default at least, not work anymore on the whole tree, but just on the hoisted part of the whole tree, displayed in that tab.

I am very confident this (equally easily to implement) feature should also appeal to a very large number of fellow UR users. (For details see over there.)