Typematic repeat never repaints screen

In Windows when you hold down a key, after a brief pause, that key begins repeating. I don’t use this functionality in Scrivener much except for the backspace and delete keys. The problem is that when I do use it, the screen doesn’t repaint. I just did a test and held the ‘a’ key down for 60 seconds. I got a single ‘a’ on the page when I first pressed the key, and then a second ‘a’ a moment later when the typematic repeating took over. From that point on the screen did not refresh once until i stopped pressing the key at the end of the minute.

This is not how it should work. Every time another letter gets added or removed, that change should be reflected in what is seen onscreen.

Frankly, I couldn’t care less if you didn’t fix this for adding text, but this is killing me for deleting and backspacing. I don’t know about anyone else, but I sometimes write two or three lines and decide it’s crap and use the delete or backspace key to remove what I had written. This bug forces me to either guess how long it’s going to take the program to delete the stuff I want deleted, or I have to sit and spam the delete button like I was playing a 1980s video game.

Please fix it so that the screen is repainted when the typematic repeat kicks in.

-Mike Riley

Could you post your system version info? I can’t reproduce this myself on Windows 7. The ‘a’ key, or any other for that matter, shows each ‘a’ that gets printed while in rapid repeat mode, as it is input.

Dell Inspiron N7110 - Windows 7 Home Premium SP1 - 64bit - Intel Core i3-2310M CPU @ 2.1GHz
6Gb RAM.

I don’t think it is my system, it think it has to do with the size of my book which is just over 143k words. I tested this in another much smaller project and did not experience this behavior.

To give you a bit more information about the project in which this is happening, here are some details:

The Manuscript folder has 37 Chapter folders in it. Each chapter folder holds zero to six text documents. Currently there are a total of 139 text documents scattered across the 37 chapters.

In addition to the Manuscript I have a characters folder that contains multiple sub folders and documents (total text documents is 147) Some of these text documents are contained ‘within’ other text documents (for example if I had a boy who had a pet that played an important role, that pet would be a sub document within the boy’s character outline.) Most of the character outlines are little more than a template for holding names and descriptive info should I need to find that info again.

I also have several folders full of world-building notes, a timeline, images and such, but none of those folders hold more than 20 documents. However, some of the images in those documents are largish.

The project folder and all contents total 11.2 MB (14.3 MB size on disk).

The last point of information that might be useful is that the project folder is contained in my dropbox folder, but to be fair, so is the other project that has only 2 documents in one folder and in which this behavior is not exhibited.

I hope this helps.


Bingo, that’s what it takes: a medium size or larger project. I tested with a ~29mb project; 185k words. The repeater got about two or three characters out before it stalled. I left it depressed for a while and when I let go about five or so added—far less than should have, given how long I held the key down.

I wonder if perhaps the indexing is updating in between keystrokes. The actual file I was in was quite small, only 350 words, so it wasn’t that the buffer for current text editor was overly large. Indexing is one of the few things I can think of that would be adversely affected by overall project size. If that is the case, images probably have less to do with it since the search index is only plain-text. For me it was stored on the local drive (but for Dropbox, that is essentially the same difference as it works by networking local material, rather than projecting networked material onto the system like traditional file sharing).

Could also be excess debugging cycles, right now. We’ll see what the experts have to say.

I’ll let Lee know. I’ve been trying this on a 60MB project with upwards of 700K words and even in a Scrivenings session with 30K words I still haven’t gotten it. Glad you’ve both confirmed, though. Maybe I should try a different machine. (The upside of this is that I now feel like my computer is super awesome. :slight_smile:)

Mike: Do you get the same lag problem in the Inspector Notes (document or project)? What about index cards? For me, the latter is full speed. So far it only seems to be the RTF capable areas of the application that are slow.

I’m sure part of it is the crap fest that is my netbook. 1Gb of RAM, cheap drive, and a 1.66Ghz Atom. This thing can barely run Windows all by itself. That said, there is a pretty difference between an empty project and a large one; and I don’t recall a problem of this magnitude in b26. I was using this same test project for larger experiments and it was running fine.

While you’re waiting for the bug to be fixed, if you highlight the text (either with your mouse, or holding down SHIFT and using the arrow keys), then you only have to hit delete/backspace once to delete your text. Hopefully that will be less tedious than hitting backspace 100 times.

Edit: Also, if you hold down the CTRL key, then each backspace deletes an entire word.

I get the slowdown in document notes, but not in the index card synopsis.