848: First "new folder tab" (when none currently exists) LOSES TREE!!

Bugs and issues - current donor version.
Post Reply
Message
Author
dsperber
Posts: 221
Joined: 28.03.2010, 01:35

848: First "new folder tab" (when none currently exists) LOSES TREE!!

#1 Post by dsperber » 30.05.2021, 21:58

As discussed in my original other thread from last year, I normally operate WITHOUT ANY TABS. I simply have one panel or two panels (vertical split screen, over/under) with an address bar. Then I navigate either panel to wherever else I want to go (thus of course immediately losing access to where I just was positioned).

Yes, this is often inconvenient and causes much extra navigation effort (e.g. to return back to where I was just a short while ago), and using TABS would obviously make my life much simpler. But I never developed that technique and thus never learned all about TABS and how to best use them. Most importantly I did not want to give up a full line of vertical window space for the TABS, when I was only concerned with a single folder and the normal address bar was perfectly sufficient. Gaining the extra line of vertical space for the tree/file list in that panel was more important to me than seeing only one folder identified in a single tab.

Image

Anyway, when I finally began playing with and learning about tabs, that's when I discovered that a simple right-click on the address bar produces a popup menu WHICH DOES NOT HAVE "new folder tab (CTRL+T)" at the top or near the top! Seems obvious to me that this clearly useful item should be in the popup menu, and in my other thread many people suggested all kinds of workarounds. I still think the simple straightforward solution is just to have "new folder tab" in the menu when right-clicking on the address bar. Period.

Anyway, I have in fact adopted one particular excellent workaround suggested in my other thread:
in settings - shell menu check the options: "Folders", "Always in the current instance", "Active panel", then click to "Update registry" and OK and then you can open new tab like this - right click the [..] item line (right below the address bar) or any folder in the file list and click "Open with FreeCommander".
I've been using this approach ever since it was suggested. Allows me to run normally in "address bar only" unless I want tabs, in which case I simply right-click on the [..] item in the file list for that folder, and then instantly I get TWO TABS (one for the current folder, and a second duplicate one that I can now navigate to wherever I want. Really perfectly fine (although I still strongly feel right-click on the address bar should have "new folder tab" in the popup menu).

BUT... THERE IS A BUG!!

If there is currently NOT A TAB SHOWING, but my panel does have both TREE and FILE LIST panes, when I initiate the pair of tabs either by (a) simply CTRL+T, or (b) right-click on the [..] item in the file list, the TREE PANEL DISAPPEARS!! I now only have the file list panel (under BOTH TABS) and I must bring back the TREE panel in both tabs with ALT+T.

Image

Image

==> initiating tabs (i.e. the pair of them, using either my method or via CTRL+T) when previously only the address bar is showing but with both TREE and FILE LIST panels currently present, this LOSES THE TREE PANEL under both tabs, which then BOTH must manually be restored with ALT+T.

Image

NOTE: once the lost TREE panels have been restored to both open tabs, from now on initiating additional tabs (e.g. CTRL+T) now retains the TREE pane in each new tab. So the "loss of TREE pane" only occurs on the very first creation of that first pair of tabs when previously only the address bar was present.

dsperber
Posts: 221
Joined: 28.03.2010, 01:35

Re: 848: First "new folder tab" (when none currently exists) LOSES TREE!!

#2 Post by dsperber » 30.05.2021, 22:25

I did a bit more experimenting. I modified Settings -> View -> Folder tabs -> Tab Management, and checked "always keep one tab open".

So now when I launch FCXE there is always one tab presented above the address bar. And TREE pane is also shown.

Image

However when I then open a second tab using CTRL+T, once again the new second tab LOSES ITS TREE PANE!

Image

And I have to once again bring back the lost TREE pane in the second tab using ALT+T.

And, just before, once I restore the lost TREE pane in the second tab, using CTRL+T again to create a third or more tabs does in fact keep TREE in each of these new third or later tabs. Only that first CTRL+T use loses the TREE pane in whatever tabs are already open or newly created by that first CTRL+T.

==> Looks like the bug is directly related to the very first CTRL+T performed (or, using my other method of right-clicking on [..] item in file list and selecting "open with Free Commander" to produce tabs).

NOTE: I have "one tree per panel" checked in Settings -> View -> Tree -> General.

dsperber
Posts: 221
Joined: 28.03.2010, 01:35

Re: 848: First "new folder tab" (when none currently exists) LOSES TREE!!

#3 Post by dsperber » 31.05.2021, 01:58

Well, it turns out the "lost TREE pane" bug is even more exotic and intricate to describe than I originally thought.

(1) Turns out that if you set "Always keep one tab open" so that there is always an initial tab showing for the upper or lower panel, well now CTRL+T will ALWAYS LOSE THE TREE PANEL for the newly created tab!!

Note that when FCXE is launched with "Always keep one tab open" the upper or lower panel first opens with just the file list pane presented, and then an instant later immediately then shifts that file list pane to the right in order to now present the tree pane on the left. This is very easy to visually see happening. There is a very visible and obvious delay in the appearance of the tree pane following the appearance of the file list pane.

I am guessing this is in some way tied to the fact the when you open a new tab using CTRL+T that the associated expected tree pane for that new tab simply does not get rendered as it should, i.e. "the tree pane for that tab gets lost".


(2) Furthermore, still with "Always keep one tab open" and with split-screen OVER/UNDER in effect, if the top panel is given focus and CTRL+T pressed repeatedly, each new tab that opens will lose it's tree pane which must be recovered with ALT+T.

But if you then give focus to the bottom panel, and now CTRL+T to get another tab there, well now the tree is NOT LOST. The new tab WILL have its tree.

And then if you give focus back to the top panel, and once again CTRL+T up there to get another tab, well now the tree pane is NOT LOST! This is different than when these steps were performed initially when the exact same CTRL+T did lose the tree. And sure enough, now using CTRL+T in top or bottom panel doesn't matter, the tree pane will be retained and not lost each time as it was originally.

Close the program and relaunch, and the whole series of "lost tree pane" can be replicated, with somewhat different effects depending on whether you use CTRL+T first in the lower panel, or first in the upper panel.


(3) Furthermore, if I now UN-CHECK the "Always keep one tab open" to revert back to my original configuration showing only the address bar, well using CTRL+T for the lower panel now behaves the same way the upper panel behaved in (2). Namely, now EACH AND EVERY CTRL+T LOSES THE TREE!! My earlier description a few posts up said that the tree was lost only on the first CTRL+T and needed recovery with ALT+T, but that it was retained thereafter if you continued CTRL+T. Well, now this is NOT true. Now CTRL+T on the lower panel will ALWAYS lose the tree.


==>> There is obviously a MAJOR PROBLEM with tabs, initiated through CTRL+T, in upper or lower split-screen panels (may not behave the same way with left or right side-by-side split-screen panels).

==> Slight variation in erroneous behavior depending on whether "Always keep one tab open" is checked or not.

==> Changing behavior depending on first CTRL+T or subsequent CTRL+T, depending on first-time in upper or lower panel, then going to the other panel and doing CTRL+T, and then returning to the original panel and repeating CTRL+T. Closing and re-launching the program wipes out previous results, and starts all over again with the same symptoms which can be replicated.

dsperber
Posts: 221
Joined: 28.03.2010, 01:35

Re: 848: First "new folder tab" (when none currently exists) LOSES TREE!!

#4 Post by dsperber » 07.06.2021, 13:54

Is this yet another bug in "tab" processing in 848?

A while back I had requested that right-click on Address Bar should show "new folder tab" right at the top of the context popup menu.

One of the alternatives methods proposed by others in lieu of having "new folder tab" in the popup menu was the following:

More workarounds, without middle button:
- in settings - shell menu check the options: "Folders", "Always in the current instance", "Active panel", then click to "Update registry" and OK and then you can open new tab like this
- right click the [..] item line (right below the address bar) or any folder in the file list and click "Open with FreeCommander".

At the time, I (a) confirmed that this did produce a new tab, and (b) confirmed that I could accept this, since it was simple enough.

Unfortunately, this NO LONGER WORKS IN 848! So unless there's more to this story that explains why something I've done or not done is actually responsible for this no longer working, I believe this is yet one more BREAKAGE IN TAB PROCESSING. I know this is unrelated to this thread which regards "loss of TREE" when opening a tab, but it is still a tab-related bug that needs to be fixed.

Can somebody else confirm that this no longer works? I've updated Settings -> Shell Menu just as the above recipe indicated. And this did previously work so that right-click on the [..] folder item did, indeed, offer "Open with FreeCommander" and it used to create a new tab. Everything but the actual creation of the new tab happens as described. But clicking "Open with FreeCommander" DOES NOTHING!

Please confirm??

Karol
Posts: 962
Joined: 19.08.2007, 12:05

Re: 848: First "new folder tab" (when none currently exists) LOSES TREE!!

#5 Post by Karol » 07.06.2021, 14:08

Can somebody else confirm that this no longer works? I've updated Settings -> Shell Menu just as the above recipe indicated. And this did previously work so that right-click on the [..] folder item did, indeed, offer "Open with FreeCommander" and it used to create a new tab. Everything but the actual creation of the new tab happens as described. But clicking "Open with FreeCommander" DOES NOTHING!

Please confirm??
No problem here. Works fine.
The simple way for creating new tab is click with the middle mouse button on any folder.

dsperber
Posts: 221
Joined: 28.03.2010, 01:35

Re: 848: First "new folder tab" (when none currently exists) LOSES TREE!!

#6 Post by dsperber » 08.06.2021, 14:53

On the possibility that my INI file has gotten corrupted, I deleted all of the SETTINGS files and started from scratch with 848. Re-customized from scratch, duplicating all of my previous changes. I did decide to make my Standard Action Bar buttons larger (not "large", but size 26) so that they're easier to recognize. I also decided to check "always keep one tab open", and also to NOT clear history when closing the program (I can always push "clear history" during the FCXE instance if I want to). Otherwise, I didn't discover any unintentionally incorrectly set items along the way.

Image

I also left "use Windows" for handling of COPY/MOVE, which was what seemed responsible for my previously reported problem of using F5/F6 when doing a COPY/MOVE from my Samsung S21 Ultra phone. Changing this to "use FreeCommander for COPY/MOVE" solved the problem of F5/F6 failing, but really there shouldn't have been a problem using Windows for COPY/MOVE as I've done for decades. Turns out it now works perfectly on the phone even with "use Windows". I can't explain the previous failure, but it has now disappeared with the rebuild of INI for 848 from scratch.

And I can also now confirm that now the right-click on [..] folder item and then "open with FreeCommander" also does produce a new tab as it should. Once again, I'm going to blame a probably corrupt INI file for the failure I reported just above. No longer fails.

HOWEVER...

(1) It is STILL true that the VERY FIRST NEW TAB tab created by selecting "open with FreeCommander" from right-click on [..] ABSOLUTELY DOES LOSE THE TREE IN THE NEW TAB!! I can get the tree back with ALT+T, and then close the tab, and then repeat the steps and now this time the tree is retained in the new tab.

==>> There definitely is a bug here, creating the first new tab using this method, with "always keep one tab open CHECKED". Tree pane gets disappeared in the new second tab, but is retained in the existing first tab.

Image

(2) It is STILL true that the VERY FIRST NEW TAB created using keyboard shortcut of CTRL+T ABSOLUTELY DOES LOSE THE TREE IN THE NEW TAB!! And once again, I can close the new tab (regardless of whether or not I first ALT+T to regain the tree), and then repeat the CTRL+T to produce a new tab, and this time the tree is retained in the new tab.

==>> There definitely is the same bug here even just using CTRL+T to request the new tab.

(3) It is STILL true that if I un-check the "always keep one tab open" (so that there is only the address bar, and no tab, when I launch the program), and then once again use EITHER of the above two methods to produce a new tab (i.e. there will end up being TWO tabs, as a new tab will be created for both the original folder that didn't have a tab showing, as well as a second tab for the "new tab"), then BOTH FIRST-TIME NEW TABS DO NOT HAVE THE TREE! That means the tree which was present for the original folder (address bar only, and with no tab) actually goes away! And the second tab also opens with just the details pane and no tree. And again I can bring the tree back in both tab with ALT+T (in each tab), then close the second tab, and repeat the new tab request using either of the above two methods, and now sure enough the tree appears.

==? There definitely is a bug here, creating the first new tab using either of the above two methods, but instead with "always keep one tab open UN-CHECKED". Now two new tabs are produced, and BOTH OF THEM DO NOT HAVE A TREE PANE.

Post Reply

Who is online

Users browsing this forum: No registered users and 3 guests