Split documents and rename problem


Keith - I of course understand this is only a beta and will patiently wait for future releases before doing work that I can’t afford to lose - and I know that 1.0 will be very solid. I just love the app so much it’s tough not to jump in and begin using it - it has so many features I’ve wished for in this kind of writing program.

Maria - although my experience with this bug did not begin with splitting the document, once it began I had the same experience you did. I’m usually pretty comfortable figuring my way through the interfaces of these kinds of programs - but there is something about this naming thing that is bewildering, especially becuase, as you too said, things begin to happen very quickly and every intuitive move you make to just get away from the problem document into another document only creates more problems - every click messes with another document, and it is easy to get confused and believe you just mistakenly created a new document that should be deleted, when in fact an existing document had been renamed to Untitled which you then mistakenly delete without realizing it.

I tried today to reproduce the problem and could not. But I will pay close attention, as Keith asks, to what triggers it. I am pretty sure that what you name the document is not relevant to the problem.

I wish I could be more helpful.


You and me both. I keep absentmindedly porting mass quantities of writing material into it, and then having to stop myself and glower at the screen.

This is regarding the problem in which one document starts taking the name of another when you click on it - at least, I think that’s what the thread is talking about.

I had this happen and couldn’t figure out what was going on. I played around with it this morning and finally discovered what I think is the problem:

  1. Edit a file name and hit enter.
  2. Hit enter again.
  3. A new “untitled” file is created. Before doing anything else, hit the delete key at the top of the screen. (this is the step that seems to start the error sequence).
  4. Click on another file name or two to move through them - everything seems to be working normally.
  5. Double-click on a file name to rename it. Change it or not - that doesn’t matter - when you hit enter, the name doesn’t take and the editing window stays open.
  6. Click on any other file and it gets renamed to the name of the file you just tried to rename. Clicking on another file renames it, too.
  7. The only way out of the problem is to quit Scrivener and restart. Then you can go back and rename all the files to their proper names.

The bug doesn’t start to happen until you double-click on a second file to rename it. The reason it was so hard to spot was that everything seemed to be working normally until I tried to rename that second file, and then everything “suddenly” seemed to start going wrong.

Hope this helps out. If it isn’t the same problem - it’s another one!


Excellent! Thank you SO much, Margaret - that is exactly the same bug and your steps have allowed me to recreate it - which means that I can now fix it.

What is happening is that when you hit delete whilst the text is still being edited, an exception is thrown by the Cocoa frameworks. And when the frameworks throw an exception, strange behaviour usually follows - in this case, what you are seeing. In beta 2, the delete button is actually disabled at this point anyway, but I still need to get rid of the underlying bug.

Fortunately, this should be very easy to fix.

Thank you again, Margaret, you have just saved me hours of experimentation - much appreciated. :slight_smile:

All the best,

Okay… And this should now be fixed. :slight_smile: At every point at which documents are added, deleted or moved, I have now forced editing to end (which is what should happen), so that these exceptions won’t get thrown. Testing so far works fine.

Yes, this is exactly the problem I had. Thank you Margaret for identifying it clearly and Keith for sorting it out! Now I know what behavior to avoid while waiting for Beta 2.