[JH] Copyholder shows files clicked in Binder, even if corresponding editor Locked in Place

Tr
Tridens92
Posts: 43
Joined: Tue Apr 19, 2016 5:43 pm
Platform: Windows

Fri Dec 29, 2017 11:41 pm Post

This bug is a bit difficult to explain, so please bear with me.

I found this bug related to the Copyholder showing files clicked on in the Binder by reproducing the below example given in the Tutorial (document "Control the Other Editor", under Going Further --> Corkboard and Outliner Tricks):

Hopefully you will see how useful this could be. For instance, here’s a setup I use quite regularly:
— Binder open on left.
— Editor split vertically.
— Right editor in outliner mode with its Copyholder open at the bottom
— “Selection Affects” button set to affect the Copyholder.
— Right editor Locked in Place (so that any clicks in the binder only affect the left editor).
With this arrangement, I can use the binder to navigate the editor on the left, and the outliner to navigate the Copyholder below it, arranging and editing my manuscript on the left while navigating through and referring to research and notes on the right.


When I set up this way, documents selected in the Binder will show in the Copyholder rather than in the unlocked editor on the left, even though the right editor with Copyholder is Locked in Place. In any case, the behavior does not match what the author of the above section of the Tutorial is indicating.

Steps to reproduce:

1) Split editor vertically
2) Alt+drag a document to title bar of right editor to open Copyholder
3) Change Copyholder to bottom position
4) Click on "Selection Affects" button in footer twice to select Copyholder
5) Change for right editor to Outliner
6) Lock the right editor in place.

You will notice that Binder clicks will show documents in the left editor, but they are synced with the right editor (which is in Outliner mode), and thus the Copyholder follows suit.

There are other strange sync behaviors with this setup too. Sometimes clicks into the outliner portion of the editor will not update the contents of the corresponding Copyholder pane. Other times clicks into the Binder will load the document in the Copyholder.

Some of this strange behavior, I think, may be linked with clicking into the Copyholder text and then attempting to navigate the Binder. Whether or not it should, clicking into the Copyholder text and then clicking on a document in the Binder will load it into the Copyholder, even if that editor is Locked in Place.


Sorry for the confusing explanation, but if you play around with the setup I mentioned above, the problems will become apparent.

Tr
Tridens92
Posts: 43
Joined: Tue Apr 19, 2016 5:43 pm
Platform: Windows

Wed Jan 17, 2018 7:13 pm Post

Just wondering if this bug I reported last month has been seen / logged. There are several other bugs I've reported as well that have not been replied to. Just didn't want them to get lost. The subjects are prefaced with "Bug:" as requested. Thanks!

User avatar
MimeticMouton
Posts: 8596
Joined: Wed May 05, 2010 5:39 am
Platform: Mac + Windows
Location: city of rain
Contact:

Fri Jan 19, 2018 10:33 am Post

I think this may be an issue of the tutorial needing to be clearer about the focus. With the right editor locked in a group view mode, binder clicks will still affect the editor by selecting the the item if it is contained in the group. (This is different from normal unlocked behaviour, which would load the item.) This in turn will then affect the right editor's copyholder.

So, for the setup described in the tutorial, you would want to have Navigate > Binder Selection Affects set to Left Editor, or if it is set to Current Editor you would need to add a step 7 and be sure to switch focus back to the left editor before clicking in the binder.

I've made a note to clarify this in the tutorial. Thanks!

Just wondering if this bug I reported last month has been seen / logged. There are several other bugs I've reported as well that have not been replied to. Just didn't want them to get lost. The subjects are prefaced with "Bug:" as requested. Thanks!

We were closed for the holidays and are still working through backlog from that, as well as continuing with development for the Beta 3 release and so forth, so we're still also catching up on the reports here. Some of them take longer to sort out and get all the information logged, but we will get to them! The "Bug" prefix is a big help in organising the post, so thank you for including that. :)
Jennifer Hughes
(MM for short)