[LH4231][LH4237] Screen re-draw issue?

(Posted in the Windows Forum initially, reposted for Beta.)

A number of things have come up just tonight, using Beta (799093) 64-bit.

First, something from the previous build: I use a graphic as a line-break indicator and until the last couple of iterations have had no problem. Now I can copy and paste the graphic from the previous time I used it - usually a previous chapter - but it places a variation of this code after the paste: <!$Scr_Cs::0> (the last figure can be 0, 1 or 2.) What’s more, after I’ve pasted the image, this code appears throughout the entire document, after each iteration of the image, (currently a 280 page novel in 43 chapters), so I have to do a complete search and replace to erase it.

Now the latest Beta: in the latest build, something’s going seriously wrong with how the program is drawing pages. I’ve attached some snips of what’s happening. Let’s say I’m writing in one chapter and I go back to the previous chapter to check something out. What I get is a blank page (first image in attachment). There’s a word count at the bottom, so the words are there, but nothing visible on the page at all. Now in this instance I’ve been writing with ‘Show invisibles’ checked (because of … well, to be explained shortly). So I uncheck Show invisibles and the text reappears. All is well. I click the down arrow to go to the next chapter, the one I’ve just been working on … and the chapter is now grossly misformatted (second image in attachment). It had been perfectly formatted before I moved back a chapter, now the formatting’s gone awry: large and small font sizes in one sentence, lines missing, the line-break image pushed left, off-screen, etc.

So I click ‘Show invisibles’ again and the proper formatting reappears. However, I can’t now add new text. The cursor either freezes completely, or the text shows half a letter when I start to type, as if it’s not drawn properly. The formatting icons (Centre, justified etc) don’t work either. The only thing I can do is close Scrivener using the Close box, then reopen it. The page I was working on now shows itself properly, and accepts text again. But if I go to a different chapter, I go through the whole loop once more.

When compiling, everything seems to be working properly. If I leave the line-break image code in the document, it’s recreated in the resultant mobi file (can’t speak to other formats, but probably the same); but everything else shows properly, whether there have been lines missing in the Scriv document, as a result of the issues above, or not.

I hope you can fix these issues quickly, because they make working in Scrivener nigh on impossible. I guess that’s why it’s a Beta … :wink:


Keith Dixon
Screen snips.doc (127 KB)

We found a problem with the drawing caused by the new replacement functionality. If you have used find/replace please, close the project and open it again. No data is lost, but redrawing the text might not work. After re-opening the project and the document it should be fine. We will release a new update on next Monday with a fix, or switch back to Beta 32.

Thanks, as I stated in my original query, closing and re-opening the program temporarily brought back functionality on an open page, but going back in to another ‘chapter’ and then returning to the original open page brought back the original problem, solvable only by closing and opening the program again.

I’d love to have gone back to Beta 32 (having just spent an hour reinstalling and updating 1.9, then copying over my recent work there :cry: ) but I couldn’t find it anywhere on the L&L site. Do you have a link? Or a procedure to roll back?

The installers for Beta 32 appear to be still present, via these links:



Presuming they’ll stay until Monday, anyway – good fortune.

Thanks! I’ll wait till Monday now, I guess …

Re-opening the project without using the text replace functionality should not cause any issues. Can you please upload a small project with few documents and steps to reproduce the issue?

Okay, I think I now understand what you meant in your first comment. If I re-open a document and leave in the graphic-separator code (that obviously I don’t want in the document after each separator), the program functions properly. i.e. I can move backwards and forwards between chapters and I don’t get any re-draw issues, so far as I can see. As soon as I use Search/Replace to get rid of the graphic code, it screws up everything - moving forward or backward from a chapter produces a blank chapter, or a chapter with lines missing, etc …

So it looks like you’ve got a handle on what’s happening and if it’s okay with you I won’t upload a document because it’s going to be a pain in the backside to organise that without sending you the whole novel … 8)

If you can arrange it so that the separator code doesn’t appear (it didn’t use to until the last 2-3 iterations) that would be good, too.

Looking forward to Monday’s release!

Glad we sorted this re-draw glitch!

About the copy/paste image resulting in <!$Scr_Cs::0>. Can you please upload a project with one document and the image separator, with few steps that reproduce the problem. Most likely you have a character style set on the image, or around the image, which is causing the side effect upon copy/paste of the image. This will help us reproduce the problem.

OK, will do. Hope the project attaches. Do you just need the .scrivx document? I’ll try that first. If you need more from the folders let me know.

Edit: How do I upload a project? This box won’t attach a scrivx document.

Archive the complete project folder and upload the zip file within this thread.

Test document.scriv.zip (444 KB)

Thanks Keith.

  1. The issue after using find/replace we already sorted out and a fix is coming in the next update Beta 34.

  2. About the trailing characters that you describe “<!$Scr_Cs::0><!$Scr_Cs::1>”. As I mentioned earlier, if your image has a character style applied to it. Copy/paste of the image causes this bug. Your demo project is not showing the problem, but most likely your original project is. To fix this, select the image and remove any style you might have accidentally applied to it. To clean the <!$Scr_Cs::0> leftovers from the previous copy/pastes, either wait for the next build, or use project search and delete this text manually, without using search and replace.

Great, thanks! I’ll wait till 34, then load the current WIP and see what we get. A quick inspection suggests that the graphic image has been associated with the Body text style … I’ll strip it out when I start using 34 and try to copy/paste a clean version in future.

Super support, incidentally, when I know you must be busy.