Indeed, the binder is saved to the drive only occasionally. So the string we read back will not track the binder’s moment-to-moment changes, but will nonetheless be our script’s most detailed map of the project. Nor would a scripter have much luck in navigating the binder through recognition and clicks, as an interactive user does. Instead, he’d automate binder travel via the Previous Document, Next Document, and Enclosing Group commands, most likely.
I place a binary rendition of the DocID into Document References, and another into Custom Meta Data. These enable a script to determine which document Scrivener is on, to match up with the corresponding document in the binder string. It’s also quite a trick to get the script to navigate to a particular doc within Scrivener. I’ve been making the case that, in lieu of a comprehensive API, a future version should build these essential capabilities into the UI, maybe meeting scripters a bit of the way.
Rgds – Jerome