When I drag a bookmark from a prior file into the “inspector/bookmarks” section of a different file, the link shows at the top and the contents of the bookmark displays immediately below, in the bookmark viewing pane, as it should.
However, if I link the same bookmark to another file, (multiple references to the same bookmark) the bookmark viewing pane becomes inconsistent. When one leaves and reenters the “inspector/bookmarks” section, the bookmark is no longer viewable in the pane below, in EITHER file that references the bookmark.
If one deletes the bookmark from one of the two files that reference it, behavior goes back to normal. This is a copy of a previous report I posted a few weeks back, but got no reply, so just wanted to make sure it got added to the bugs list.
Sorry, klester, can I ask for some screenshots from each step above, which will demonstrate the problem. I could not understand and reproduce the problem that you explain above. Thanks!
Here ya go, Yes, it is a very difficult anomaly to describe without pictures.
I made a test file “bookmarks_test” which I have attached to the next post, so you can experiment. Here’s the screen before any bookmarks have been created. You will see three files which should be self explanatory. In this screen shot below, nothing has been bookmarked yet.
Next, I dragged the file “File to be bookmarked” into the bookmarks section of the inspector (of reference_file_one). Note that the bookmark bar is highlighted blue, indicating that I have selected it, and the contents of “File to be bookmarked” is shown below it in the large blue box. So far, everything is working as it should be.
Now, in the screen below, I have dragged “File to be bookmarked” into the bookmarks pane of reference_file_two. This is when things get weird. You can again see, by the blue highlight, that I have selected the bookmark in the inspector, but no contents are displayed. Instead the bookmark contents panel reads “no bookmarks selected.”
Once the same file or folder has been bookmarked in multiple other files, the behavior becomes inconsistent. The bookmark reading pane fails to display the contents of the bookmarked file, yet sometimes it does, (weird) I can reliably repair behavior by deleting the second reference to “File to be Bookmarked” from “reference_file_two”
I suspect this weird behavior is due to a circular reference issue. As you can see from this next screen below, circular references to “reference_file_one” and “reference_file_two” were added automatically to “File to be Bookmarked” I DID NOT create those circular references. They appeared spontaneously due to me dragging the “File to be Bookmarked” into the other two files. Interestingly those two circular references can be deleted manually, but that doesn’t fix the anomalous behavior in the other two reference files.
Note that I have also attached a backup of this test file so you can reproduce the issue live. It’s really hard to explain.
PS: Although this behavior may seem obscure, there are many instances where referring back to a previous file later on, becomes very useful. For instance, you might have a list of characters that you want to see in the right bookmarks pane while writing another chapter. It would not be unusual to reference the same file in multiple other files. I wouldn’t complain about this being broken, except that when it works right, It’s REALLY great! Bookmarks_test-bak.zip (425 KB)
Now that (I hope) I’ve spelled out the specifics of the programming anomaly, let me emphasize why correcting this behavior is so important.
Let’s assume you are George R. R. Martin, and you are writing Game of Thrones. You have literally, HUNDREDS of characters that move in and out of your story. Can you remember and keep up with every major and minor character when writing new chapters? Probably not.
So, assuming Martin was using Scrivener, he could compose a quick alphabetical list of characters and a one line description of their purpose, so that when writing a chapter, he could refer back to this list. Or, maybe it would be better to organize characters by region on the GOT map. So you might have two characters files: one organized alphabetically, and one organized by region.
You’d want to attach both reference files to every chapter in your new GOT novel. That way, you could quickly refer to the character list when writing a new episode, regardless of which list is most appropriate.
That means, that Scrivener must be able to display these multiple bookmark references quickly and easily in any and all chapters. Therefore, correcting the display of bookmarks is a very important bug fix!
Now that I have expressed the need for bookmarking to work properly from a writer’s perspective, I thought it might be good to reference the problem from a programmer’s perspective. (since I’m an old grizzled programmer)
I’m hoping I’m wrong, but I suspect this bookmark limitation is a result of inadequate database design. For instance, the simplest database design would entail “one-to-many” data relationships. IE: an invoice is the parent (one) and the invoice line items are the children (many) This structured database is simple and easy to program.
Things get infinitely more complex when there are “many-to-many relationships” which usually require at least a third database link file to determine who is the parent and who is the child in every single record.
Since Scrivener allows multiple bookmarks from multiple sources and from within its own database, the structure fits the classic “many-to-many” relationship. I suspect that once a file is referenced more than once, it becomes the parent, but since many files can be referenced by many other files, there is no true parent-child relationship.
I hope this isn’t the case because it would require a major database restructure, but does the Scrivener database take many-to-many relationships into account?
Thanks for the detailed report and screenshots! I’ve added this to the list. It looks like it’s just a refresh issue, so hopefully not so dire to solve. Loading a different document in the bookmark pane allows the original bookmark to load properly again when selected. The “problem” bookmark should also load correctly when switching between documents that have different lists of bookmarks, even if it is the one that is pre-selected to load. If you’re seeing the same thing, hopefully that will provide you a fairly easy workaround until we can get this fixed.
