Scrivener 3.1.1 for Windows does NOT maintain cusor positions when navigating between multiple documents, but Scrivener 1.9 DOES

Scrivener Scrivener for Windows
1

I typically work on HUNDREDS of documents at a time in the binder, across dozens of integrated books. It is essential that when I navigate (e.g., forward or backward) between documents, that the cursor remains where I left it in a given document and that I can find that by clicking on the vertical scroll bar adjacent to the current document and pressing a key to enter some text, so that the document automatically shifts to the cursor location, where I can simply use backspace to delete the inserted character. In Scrivener 1.9.7, for example, that all works perfectly, including when I exit the application and restart it, in which case the cursor position is still properly maintained across multiple documents as I go forward or backward from where I’d left off, in each one.

In Scrivener 3.1.1 for Windows, having just tried it for the first time after licensing it via the upgrade process, I find that I am “lucky” to have the cursor placed in the right spot (where I left off) for the last open document ONLY, and that if I navigate forward or backward in the list, I find that the cursor position has been LOST for all other documents. Moreover, I cannot just click on the scroll bar to the right of a given document, to which I’ve navigated backward or forward, and press a key to insert a character wherever the cursor is (and again, the cursor is in the WRONG spot, as in the location is simply lost for all but the latest document upon reopening a project).

For me, when working on so many documents in a project, which span multiple books in the binder, this loss of proper functionality in Scrivener 3.1.1, makes 3.x UNUSABLE, forcing me to stick with 1.9.7. I view this all as a bug that has gone unreported and unfixed between 1.x and 3.x.

Please advise, and please put this bug as a high priority to fix. Thanks.

2 Likes
2

It only loses its position when one of the documents has a subdocument and is viewed in scrivenings mode. Otherwise, it works for me.

1 Like
3

I have created a test project that has the cursor placed in a few different areas, and has a word selected in one case. I clicked on each item in a row, so you can use history to walk back through them, and the should all be working.

history_and_cursor.zip (151.3 KB)

Things to note:

  • Yes, the keyboard focus gets lost when using history. This is a bit of a bug that needs to be fixed. You can get back easily enough with the shortcuts in the Navigate â–¸ Move Focus To â–¸ submenu (note the top entry cycles between the binder and the two editor splits).
  • If for some reason the scroll position isn’t showing the cursor, Ctrl+J, or Edit â–¸ Find â–¸ Jump to Selection will do that in a purely passive way, rather than risking overwriting selected text with a letter when you type.

So the question would be, if that works for you, what sort of actions should I take to see what you’re describing. What sequence of events does it take to see the cursor position get dropped. I do suspect, as @krastev noted, that Scrivenings might be an ingredient. There are some natural limitations there, but these typically involve what happens in the session itself, rather than outside of it, if that makes sense.

1 Like