Corkboard Text Will Not Display

I am new to Scrivener, and after creating a number of folders and entering content, including Corkboard cards, I did some rearranging in terms of hierarchies. Now, none of the text in my Corkboard cards will display. I can see the title I gave to each card, and I can search on text within the cards, but the text will not display (I just see a blank card with the title on top).

Anything I can do so as not to have to recreate this content?

Thanks.

Hello,

Are you saying you have already typed some text into the cards, and that has now disappeared? Or have you just typed text into the documents associated with the cards? Index cards are there to present synopses of the documents they represent; they do not show the text itself. It’s up to you to type synopses in (or to auto-generate them using the button in the inspector or the option in the Documents menu). I recommend refreshing your memory of section 5a of the tutorial, which explains how the cards work, if this is the case; if you have actually typed text directly into the cards and can’t find it, though, then that is unexpected and we’ll have to walk through things a little more.

All the best,
Keith

I actually typed text into cards, adding multiple cards in some instances. I understand that cards are separate from and supplemental to my Document (View). All the cards that exist were added by me with text in the main part of the card–now all that I can display are blank cards with the title (I originally provided) at the top. And, like I said in my original post, I can search on text within the cards, and the “found” cards will list in the Binder, but they display blank.

This appears to have occurred after I moved folders that were once secondary level to a third level, grouped under a secondary-level folder.

Thanks.

I have heard, I believe two reports, of similar issues. It seems that in very rare cases card titles and/or text can be susceptible to data loss or duplication (multiple cards acquire the same data). I have no really solid clues to go on though. I’ve never seen anything like it myself, and even for the people that have experienced it, it is a sporadic thing for them and they can’t produce a list of steps that will reproduce it even on their machine. Possibilities: auto-save issues; outliner editing conflicts; and lots of rapid work where all edited cards lose data (which again could be tied to an auto-save issue).

Intriguing is that search results work. It might be that the search index file got saved correctly but not the .txt files. If you don’t mind digging in the project a bit, I’d recommend checking the actual data on the disk. Don’t close the project. Leave it open so that its current state is preserved. In Finder, right-click on it and choose “Show Package Contents”, then in that window navigate into Files. First off, Option-drag a copy of search.indexes out to your desktop. That might be the only thing left that has the stuff you typed in, so this will make a backup of it. Next, navigate into the Docs folder. Synopsis cards store their data in plain .txt files. They’ll be numbered, and if you have typed in document text or notes, you should see them grouped together by number. So example, “23.rtf” with “23_notes.rtf” and “23.txt” rtf. That would be the main text, document sidebar notes, and the synopsis card data, respectively, for one particular outline node in the binder. “32.txt” would be the synopsis for another binder item entirely. So that’s how that works.

So just poke around here and look for .txt files. Quick Look them and check to see if they have the text that is not showing up in the interface. If they do, then the good news is that it sounds like a display error. Perhaps a font colour problem or something. I would at that point try wiping the preference file and re-installing Scrivener, to eliminate any preference or UI control file weirdness. Though before taking that step, I would check the Appearance preference tab in the custom colour section and make sure the index card text colour is not set to white.

Yikes, I’ve never heard of that happening! I can’t see how synopses would disappear in such a situation anyway - and titles even less so. When you type a synopsis, it will get saved to a .txt file inside the project during the next save or autosave, and if it fails to write to disk then an error will be thrown which will be very clear - it’s an alert panel. True, if saving didn’t get called at all, then you might not see an error, but if the search results return the information, then saving must have been called. Once the .txt file has been written to disk, it’s only touched again if you make changes to the synopsis - moving things around or changing the hierarchy of documents has zero impact on the synopsis .txt file. So this is very strange indeed…

Maybe you could zip up and send us the project for examination?

Thanks and all the best,
Keith

Ioa,

Thank you for your comprehensive response. I have located the synopsis.txt files and copied them to another folder; I now have access to them as plain text (which will save me a few hours in not having to recreate them).

Keith,

Oddly enough, the Corkboard cards are now displaying normally. My overall Scrivener project file is such a mess that I am porting everything out and will rebuild a leaner, meaner project down the road. Hopefully this was just some quirk resulting from my own project management.

Again, thanks very much to both of you for your help.

Bob

It does sound like a display error then, that’s good, it means the data is all intact and no work is lost. It just means the code designed to display the data is for some reason malfunctioning. If you get the problem again, there are a few steps you can take. Again, from the prior post, flushing preferences and re-installing the software is a routine first step for getting rid of weird interface issues. Another thing to do is reset your font cache. It is easiest to use a system maintenance tool for this. I recommend the free and easy to use Onyx. It has a panel for flushing system and user cache files. You do that, then reboot. It will rebuild the font caches and a number of other things (so the first reboot will be slower than you are used to).

In short, this doesn’t sound like the same problem the other two were experiencing. Like Keith, I have no idea how that bug happens, but I’ve seen screenshots of it happening—that one does seem to be a data problem though, so I think you are clear of it since the .txt files were fine.