When making changes to a .scrivx in ProWritingAid I save the change (overwrite). I shut down ProWritingAid, and launch the project with Scrivener. I have noticed that the changes made in PWA do make their way over to Scrivener but the Word Count does not change. Is this a bug? Is there a way to force Scrivener to recount the words in a project?
I would be curious if after you reopen Scrivener, if you delete one word would that force scrivener to do session recount and then reflect changes from PWA edit?
If I add a word in PWA, it shows up in Scrivener but the session count does not change. If I then delete it in Scrivener, my session count goes down by one. Another test I did was deleting 2 words in Scrivener, session count reflects this. I then add the same two words back with PWA, close that, reopen Scrivener and the words are there AND the session count is modified. Is this a huge deal? No. I only noticed this because I’m doing the NaNoWriMo challenge and there is a daily goal to achieve. Usually the project count (which seems to always be accurate) is the only number that might matter. Thanks for the feedback
and suggestions - I appreciate them!
Probably because PWA reverse engineered the file format for their own purposes and Scrivener has no programmed way to accommodate a third-party hacking the file format. — neither should it give them any space.
I’ve been digging into the files a little bit and have thus far found:
When a change is made to a document, it does write to \Files\Data{data token}\CONTENT.RTF with any changes.
What it does not write to, and maybe could, is:
<projectname>.scrivx
If it updated the element, , when Scrivener is restarted, it reflects the new value.
I also think that I should be able to allow PWA to write to this file (I manually updated this to test) but perhaps it is a PWA issue whereby it is just not updating that value. Anyway, I always find it interesting to dive into the guts even though this is just a minor inconvenience to me.
You probably don’t want PWA to edit the .scrivx file.
It’s the master index to the project, so corrupting it accidentally can render some of the components of the project inaccessible.
It’s also an XML file. It’s relatively human readable, as such things go, but it still needs to have things in a precise order with all of the special characters in place. Parsing it is a completely different task from parsing text to determine whether commas are in the right place. So to edit it safely, PWA would have to write a completely separate engine, just for us.
And because it’s such a critical file, Scrivener keeps a couple of internal backups. If it detects that the .scrivx file has been changed outside of Scrivener it can (and should!) throw an error and ask the user to resolve it. Which would probably make PWA’s customers sad.
Directly editing the content.rtf files is reasonably safe. Directly editing the .scrivx file outside of Scrivener is very much not.
So is there a way to force Scrivener to recount session and\or project word count? Perhaps it’s not feasible and that’s ok by me. I was more curious about the process than needing an accurate session count. Again, thanks and thanks to all who contributed to this thread.
The project count should always reflect the actual number of words in the project, from whatever source. If it doesn’t, that’s a bug and we should look at it.
The session count is a lot more fragile, since it needs to keep track of when words were added. It has some known issues when editing with Scrivener on another device, too.
To clarify on this point, we make the full project specification files available to any developer that asks, and there are multiple official ways for third-party tools to work with the .scriv format safely, and even add their own metadata to the project for their purposes. And even if one doesn’t ask, the whole format was designed to be human-readable and easy to figure out.
That said, there is no stipulation that the third-party developer be as thorough as Scrivener is when editing a project. If they don’t implement updating the writing.history file or update the session counter and timestamps in the .scrivx, that’s on them. It’s not something Scrivener would be able to do on its own or repair, as it would have no way of knowing anything has changed at that level.