Hi.
If I my memory serves me well, Scrivener used to remember where the cursor/selection was in a specific document when the project was saved and closed the previous time.
Upon opening that project, the cursor or selection would be in the displayed range of that document. (Dead in the middle, if using typewriter scrolling.)
But although Scrivener still remember that cursor/selection emplacement, the displayed range of the document(s) is now off when reopening the project. (Meaning that I have to scroll to find it)
The visible range seems somewhat random too: although it is always opening to the same position, given that I don’t further edit the project, then close it, and reopen it (yes, it changes from time to time), I can’t think of any reason why this ends up being the displayed range when opening the project/document - that ain’t a section of my text I worked on during my last session.
P.S. That bug - if one - is fairly recent. I don’t recall having that issue using the beta.
I don’t think that means what I think it means, because it doesn’t work. The only way I can get a cursor in a text panel that I come back to is by clicking my mouse, and the cursor appears where I click the mouse, not where it was last in the text panel when I left.
The keyboard arrow buttons do nothing but for the left-arrow. It puts me into the binder.
Hitting the “down” key (then the “up” key, so that my cursor goes back to the line it originally was on) works for me as a half acceptable solution.
But I never had to rely on a trick like that before… (If I remember right, that is - I spend long periods writing longhand, and also use LibreOffice for my final Ebook formatting, so it gets confusing sometimes as to what software used to do what. Although in this case I am pretty sure I remember it right, given the fact that it is somewhat a sudden pain in the ass - no offense intended.)
Downside of having to refocus the displayed range this way: if you had selected text, the selection is lost.
And if you closed the project after tweaking anything else than the document itself (the text), it then doesn’t work.
I think I figured out what the problem is :
If before saving my project (or simply closing Scrivener) I move the focus to another document in the binder, then the initial document as it’s displayed range right upon reopening the project.
In other words, it seems that for some reason, Scrivener doesn’t “memorize” the very last scroll position when saving a project. (It rather keeps going back over and over to the last one it has. So, even if you tweaked a document, and even a lot, as long as it is the last document you had displayed, the displayed range will go back to what it was before doing so. Might even be to what it was a couple sessions ago, if you pretty much end up having worked only on that specific document, or ended all those sessions with this specific document active.)
Yeah … I haven’t seen the “cursor missing” situation, so I couldn’t properly test my solution. However, I think you can get Editor focus with Win+Shift+E before using an arrow key.
It would seem that the displayed portion of a document is also influenced by the place (in the document) where text was last added. So it is mostly a problem at the revision/rereading stage.
Figuring this out though, I came up with a trick to override the issue, taking the habit of inserting a space, then hitting backspace before moving away from a document. Not wonderful, but it works.
P.S. I should also append my initial post by saying that the issue manifests itself not only when reopening a project, but also when simply navigating from a document to another, then back. (In other words: all the time.)
Things just got a little stranger:
Since the last windows’ update, the issue seems to be gone…
I don’t like when things fixes themselves (meaning they may go wrong again at any time), but what can I say, everything is back to the way it should be. My cursor is visible now when opening or reopening a document. The display position of the documents is memorized properly now by scrivener.
The “trick” I spoke of yesterday (previous post) probably had no part in the solution in the end… Just changing the cursor position was probably enough (as should be) .
I’m just not sure where the coïncidence fits in all of this: just as I thought I had found a fix, the problem resolved itself; – pretty much right after, although I did some conclusive testing first…