Locking a tree

[Stef123]

Not sure I understand the function of Lock Tree. My intention: Drop stuff onto the tree but don't allow the tree switch to my source folder. I want it to stay where it is, at the intended destination position.

My Steps:
1) Pane1: I see a folder close to my intended destination - I click on it
2) the tree shows the neighboring branches - YEP, just what I want, these are my drop locations, so I lock the tree
3) Pane2: I drag my stuff over - but hey, the locked (and greyed out) tree syncs to the source folder - my destination branches are gone

[admin]

If a folder exists (the node is visible) in the locked tree the tree will sync.
If a folder does not exist in the locked tree the tree will not sync.

But I understand your issue. I myself never use the locked tree so I have no personal opinion. So I ask the locked tree users out there: Should the locked tree never sync?

[grindax]

.

[Stef123]

@grindax,
Could you explain the advantage a locked tree offers to you - in comparison to a regular tree - if both sync to existing tabs?

I was hoping to achieve this mouth-watering feature from the help file :

A Tree bypassed by browsing (i.e. the location shown in the file list is not shown, let alone selected, in the Tree) is displayed with a grey background, resp. with the color you have defined for a Locked Tree. This makes it immediately clear that Tree and List are not synced at the moment and protects you from false assumptions and potentially fatal decisions.
...
It keeps the Tree in a stable state and position while browsing. For example, this can be valuable when collecting stuff from various locations via drag+drop into a couple of target folders - no need to scroll the tree anymore: the Tree just sits there and waits.

To achieve the above, I first have to scan my tree to make sure it does not show the source folder. Then I lock the tree. Then I drag my source to the destination.

This involves collapsing a bunch of nodes that I later need to expand again because in general, I'd like to see those nodes instead of having all those branches open in multiple tabs. I fail to see the rationale behind this behavior - what am I missing here

[grindax]

.

[Stef123]

As I move from tab to tab, the highlighting in the tree changes appropriately depending on where I am.

Well yes, sure, but that's what you get with a mini-tree as well. A reduced tree with custom locations and custom node states. Or you could set up a catalog that mimicks your favorite flat tree levels, if you're concerned about quick navigation.

I understand the dynamics, but I cannot think of a practical, real world example that would make this locked tree behavior more reasonable than what I quoted above from the help file.

Let me try the other way round: Just like you're using the lock in a different way from its original intention (so it seems to me), maybe there is another way I could change some other feature to make it behave like the help file promises: Breaking the link between list and tree, allowing me to do this:

• - browse quickly through a bunch of nodes in the tree
  - freeze it
  - drag+drop from ANYWHERE
  - unfreeze and continue further down the tree, freeze again, drag+drop etc.

Any suggestions how to achieve this?

[admin]

If a locked tree would not automatically scroll a synced node into view, that might be enough to make/keep you both happy?

[Stef123]

Absolutely. Only speaking for myself, of course.

[grindax]

.

[Stef123]

Thanks grindax,
I cannot reproduce it, been trying all kinds of combinations of settings. But you're right, there seem to be other workings behind the scenes, because I get very different results with the same settings, depending on whether I have the catalog (!!) visible or not.

Let's take it one step at a time, in a clean tab layout, two panes next to each other, both showing only one tab each: 1.1 showing C: and 2.1 showing D:

• In the tree: expand C:\Windows (that should give enough subfolders to make it jump) - now lock it - pretending that the Windows subfolders are our desired drop locations.
• Now click 2.1 and drill down into D: to fetch our drop-sources. As soon as I do this, the locked tree jumps down to D:\DropSource.
• Clicking back and forth between tab 1.1 and tab 2.1 will jump the locked tree up and down between C: and D:\DropSource.

As I add more tabs 1.2, 1.3, 2.2, 2.3 with deeper folder locations, tree jumps are getting worse at first, but then after a while - repeatedly switching back and forth between the panes - the tree will eventually stop jumping around.

Sounds weird, but this was a live coverage of the events happening on my screen.

[admin]

Good news: The unwanted syncing of a locked tree on pane switch is actually an unwanted side-effect of a bug fix in v11.70.0004 - 2012-10-09 18:28. In other words: it's a bug! Fix comes...

[Stef123]

I see what you're saying - it does not happen when switching to other tabs of the same pane, only when the other pane is involved.
Case solved.

[admin]

Yep, thanks for reporting!

[Stef123]

Thanks for fixing. Now it works like a charm, the way as advertised.