Probably not a bug, but may be fixed...?

I noticed the following behaviour of the Binder and I wonder if it can be changed, or if I should change my clicking habits:

I often work in the corkboard, editing synopses or shuffling stuff around. Once finished I click on a file in the binder which happens to be part of the current corkboard session, but nothing happens. Usually I want to select that particular file and exit the session in order to take a snapshot of the file or edit it further. To me it’s the most intuitive thing and the thing which seems most natural to do, but it doesn’t work.
Can you advise?
Thanks! Ptz

That most certainly is the way things work already, at least it should be. Could you please give more details, with a step-by-step breakdown? (Please refer to the post at the top of the forum about how to provide effective bug reports to make it easier for me to see what you mean.)

sure, you’re absolutely right, here it goes then: I isolated a specific situation - the latest I incurred into, and it’s slightly different than the above inaccurate one, but here it is:

1 Have two folders ready in the Binder with a few files in them.
2 Click Folder 1 in the Binder, enter scrivenings mode for that folder
3 Lock in place
4 Make some edits in the files to mimick real life - it doesn’t matter in which file
5 Click Folder 2 in the Binder: nothing happens because you just locked the scrivenings (doh! but it happens often in real life - in mine, at least!)
6 Unlock the scrivening session by clicking on its command with the mouse
…What you should get now is this: Folder 2 is selected in the Binder; you still are in scrivening mode for Folder 1 in the Editor.
7 Click on Folder 2
…Here’s the issue: nothing happens. No matter how many times you click, Folder 2 doesn’t get displayed in the Editor.

Let me know if all the above is clear enough!

Have you tried clicking on another document in the binder, then back to Folder 2? It’s possible the binder selection changes the editor only when the selection is first made, and not on subsequent clicks.

…yes, that allows me to continue, but it also exposes the fact that it is an issue, or in any case not the desired behaviour: that is, just one click on the desires file in the binder to display the file in the editor.

I disagree in that unlocking an edit session should automatically leap to whatever happens to be selected in the Binder. The main reason for this is that the editor never follows the Binder selection; rather the other way around (unless locked of course). To test this, click on a few documents and then use the Back button (that left arrow at the top of the editor) to view the previously clicked on documents in the history. Note that the Binder selection does not jump around when you do this. While that might seem slightly unintuitive, there are reasons for it. Mainly, the Binder wants to respect your adjustments of it unless you specifically tell it otherwise. It will not collapse or uncollapse sections unless you tell it to. This keeps your session tidy and the way you want it to be, rather than an unfettered thing over which you only have partial control. Where this comes into play most is Scrivener links. These can take you anywhere in the project, and to update the Binder appropriately might necessitate large “hidden” areas of the Binder suddenly being revealed. So when the editor is unlocked, this is another condition where the Binder may not be “synchronised” with the editor.

The second click requirement has no tidy explanation, though. I’m sure that is merely a limitation in the underlying tree view code that the Binder uses. I could be mistaken on that score though.

Ah, I don’t think this is an issue at all - janra’s solution is the correct one. You will find this in many such programs. Because the folder is already selected in the binder and the binder already has the focus (the selection is blue rather than grey to indicate focus), indeed nothing will happen. This is because as far as the binder is concerned, nothing has changed - this is how controls work in OS X. It only sends out a “selection” changed message to the rest of Scrivener if the selection actually changes, or if it gets the focus when it didn’t have it before - again, this is the same with other applications (I’m used to this in Xcode, for instance). So, you just need to click into the editor and then back into the binder to “tell” the binder that something has changed. Even if I thought this was an issue (which I don’t :slight_smile: ), I doubt there would be much I could do about this because the way controls such as tables and outline views (such as the finder) receive click and selection notification is hard-wired into the AppKit (the OS X controls themselves).

All the best,