I imported an RTF file from a Final Draft 8 script and since some of the formatting for HEADERS and CHARACTERS did not come though as ALL CAPS, I had to manually change them.
Going through the menu> submenu is way too time consuming so I used (CTRL>SHIFT>A) using the auto hotkey that Stefan kindly sent me
It works OK for 2, 5, or even 10 corrections then Scrivener crashes.
I restart. Do several corrections, then another Scrivener crash
I’m also finding that Scrivener is taking longer and longer to start when I’m working on my novel. The Scrivener folder for the novel is 93 megs, as I have a lot of research material. Could that be a problem?
Just now I opened Scrivener. Since I’m presently working on the novel mentioned above, it was the default project. The program simply froze (the “not responding Microsoft notification” popped up)
Help! I’m scared I’m going to eventually lose data
thanks,
Marta
WINXP SERVICE PACK 3
What happens when you manually correct 10 headers instead of letting ahk do it for you? Does it still crash?
Though I’ve never heard of any problems with an ahk-script as simple as the one you have in use, it’s worth a try.
If I remember correctly, your temp folder is getting cleared out automatically, on a regular basis. Does it still crash when you keep your temp files? Maybe Scrivener depends on these stored “crash” data with increasing project size, as a recovery fallback. Until the issue is solved try leaving the temp folder intact.
Have you imported from FinalDraft before? Does the same rtf cause no problems when you first put it into a basic rtf-word processor, then take it from there into Scrivener?
To convert to uppercase the slow way, here is an alternative to calling up Format > Convert by hand:
At the end of your ahk-script, insert the following:
It will simulate the keystroke ALT RC which calls up FoRmat > Convert. You should see a brief flicker as it does so. #IfWinActive restricts this to the Scrivener window only. In all other windows Ctrl Shift A will not have this effect.
But I don’t think the crashes are related to ahk.
Maybe the size of your RTF causes performance problems with autosave. Try raising the default 2 s to a less frequent value. I don’t know about fragmentation etc, but it seems that a higher value gives my PC more time to breathe.
Hi Stefan
The AHK is NOT the problem. It worked without crashes or problem on all of these:
Tried the RTF in word 2007. In final draft 8 I tried both RTFand FDX. I also tried a TXT file in several text editors. It also works in both Firefox and IE 8
I then went in Scrivener opened up an entirely new script rtf import. Scrivener crashed almost immediately. I was able to do only two changes.
BTW: my script projects are not big–average is about 16 megs. Only the novel is big, and I never tried to do an ALL CAPS as it is not an issue
I made sure the temp folders were there, so that is not the problem.
Stefan,
Do you mean that perhaps my drive needs to be defraged?
I have a large HD, and work on 100+ mg images in Photoshop without any problems
Having worked on a PC since Win 3.1 with a small drive, I got into the habit of defraging regularly even though it is said that it is no longer an issue with the bigger drives.
I will reset the auto save in Scrivener to 3 minutes between auto saves, but do notthink that’s the problem
Marta
You’re right, Marta,
this has got to be an intrinsic bug inside Scrivener, unrelated to what I surmised. Like you I juggle large Photoshop files and huge Samplitude projects, heavy stuff compared to text files. But nothing keeps my PC as busy as Scrivener does, LEDs flickering, hard drive humming, fan blowing.
What you reported scares me. I hope someone keeps track of this and other issues so it stays afloat amidst all the cheering and literature and latte. Patches and bug-fixes seem a bit slow considering the seriousness of some problems.
Stefan
I think Lee is back from a well-earned vacation so, hopefully, these issues will be resolved soon.
Never heard of Samplitude before, but googled it and it’s a music program?
Scrivener is heavy but not as much as java based programs-- like the blurb book publishing software-- that one is like working in molasses, but admittedly does a perfect job.
Didn’t mean to say the devs here are lazy. Maybe too few of them. In contrast to the many forum moderators, who are doing a great job. What I miss is structure, repositories for known issues.
2000 topics in Bug Hunt, a vat of spaghetti without forks. No sticky topic to keep track of confirmend bugs and their status. You run into a problem and either have to pull out long threads or throw yet another one on top of the pile.
Yes, Samplitude is a recording software, continuous I/O streaming of massive amounts of data, and yet not nearly as sluggish as Scrivener. Every software has bugs, of course. But when you work professionally, you cannot excuse missing deadlines with the well-deserved vacation of your tool-developer. :mrgreen: Not yet. Maybe it will become more wide-spread and acceptable in the future.
Have you checked Task Manager when you launch Scriv to see what amount of CPU Scriv is using?
Stefan had asked if you can make the corrections without use of the script - have you tried that at all?
While a script may function in other programs, there might be something about it that causes some hiccups in Scriv.
You may also want to check your Event Viewer.
Click the Start Button, right click “My Computer” and select “Manage.”
Look under the event viewer immediately after a crash and see if anything is listed.
You can also click the Start Button and type “reliability” into the search box and click on “Reliability History” and see if anything comes up as having crashed.
If you can get application logs, feel free to post them here.
I checked the CPU reading. I had Firefox up and it had a zero reading in CPU but when I pulled up Scrivener it jumped up to 67%, then when Scrivener finally came in completely it settled down to 4%. Don’t know if this is normal or not as I’ve never looked at it before. I do know that when I’m working on the novel, Scrivener takes forever to pull up. ( I have 4gigs RAM, if that means anything)
Yes, I can make the ALL CAPS correction without using the . AHK script, and did about 4 of them like that , but it is WAY too time-consuming to go through the entire screenplay with Scrivener 's present set up of
SELECT section to be changed
go up to TOOLS menu.
Scroll down to CONVERT
scroll right to TO UPPERCASE
Found the event viewer, but my path is different. It’s not under start menu. I right clicked the computer icon on the desktop, selected “manage”. Under event viewer. I see errors listed, but it does NOT say which program caused the errors.
windows could not find “Reliability” when typing “reliability” into the search box
Have you tried using Format > Scriptwriting > Re-capitalize Script? I may be misunderstanding what’s going on, but if all the elements are correctly identified in the footer and the problem is just that, e.g., the scene heading is lowercase but should be capitalized, this menu option ought to do that for you in one go. It does depend on the elements all being correct, though, so if you place the cursor in the scene heading text, for instance, and it doesn’t say “Scene Heading” in the right of the editor footer but instead is something else like “General Text”, you’ll need to correct these first. In doing so that may correct the capitalization as well, at least lowercase to uppercase. This will be a bit time consuming at the moment, I’m afraid, as we don’t yet have a conversion system in place, but you can speed it up a bit by using the keyboard shortcuts for the elements as you go through, Ctrl+\ to bring up the elements menu and then the applicable single-key shortcut for the element (these will differ depending on the script format but are listed in that menu).
That doesn’t of course explain why Scrivener is crashing when you try to use the AHK script, but it may at least solve or help the immediate problem. Would you or Stefan be willing to send the script my way (post it here or send it to windows.support AT literatureandlatte DOT com) so I can try it out? It’s possible there’s a conflict going on between ATH and Scrivener, unrelated to the actual script itself (or maybe related–I think some other users have successfully used various macros in Scrivener, but there might be something in this one that Scrivener is getting fussy about). Just so I’m clear, too, for testing this, the crash is happening for all your script projects, even those with short documents? If you create a sample script document with only about 500 words, 10+ lines that need the capitalization adjustment, does Scrivener crash when you run the ATH script?
Regarding the lag and freeze with your novel project, a few things to check:
Is your project saved on an external or networked drive? That would take longer to load than if it’s on your main C:\ hard drive and could be introducing some lag, so if you are working remotely try moving the project folder (when the project is closed in Scrivener) to your user Documents folder or the desktop and give it another go.
As Stefan suggested, bumping up the auto-save slightly may help with lag when you’re working in the project, although it probably won’t make a difference for the initial load time.
93 MB is pretty large, and as you said, you have a lot of research files, so at this point I’m guessing that unfortunately at least a portion of the lag you’re experiencing may just be due to that. The more items you’re displaying in the editor, particularly in a Scrivenings session but also on the corkboard, the longer it will take Scrivener to load it. If you leave the project in this state when you close, then when you reopen Scrivener has to load everything again–so again, this would contribute to a longer load time. If you can, try working in smaller sections–e.g. create some folders or sub-folders in the binder to group your research notes in ways pertinent to you so that you can select smaller groups to view on the corkboard or in Scrivenings. Lee’s working on some optimizations, especially for Scrivenings mode, so we should be seeing performance improvements over the next few months as he’s able to do that; ideally of course you should be able to work with quite a large project without getting lots of lag. For now though some of the above may help.
You may want to go to Tools > Options… and in the General tab, disable the option to automatically load your most recent project. That way at least you won’t get Scrivener completely freezing up when you launch if it’s trying and failing to load the novel project correctly.
My screenplay rtf (saved from FINAL DRAFT 8.0.3 build 120) looks and acts correctly in word (when headers, action or characters, etc are selected, they are listed correctly and look correct. ) However, the import engine in Scrivener changes everything to general text.
In addition, in Scrivener the left side indents one inch more than it’s supposed to. (this is something I reported to Ioa at support, and she said she’d let Lee know about it)
To make it compile correctly I would have to reformat the entire script line by line or at best, in some areas, section by section. Not a fun task when you have 6 scripts to import, to say the least. That’s why I am hoping that Scrivener will soon be able to import a FINAL DRAFT document
I changed my auto save to 3 minutes several days ago, but see no change in how the program reacts.
Yes, all my projects (writing , research, photography, etc) are saved to a second INTERNAL drive, (but it is NOT on a network–it’s inside the same computer as my OS). I only use my C drive for the OS and programs.
I just sent you the .AHK script to the email address you requested. Yes, the crash is happening in ALL the screenplay documents, and they are all very small (the novel --the only large project I have-- doesn’t need it, so I’ve never used it there)
since the project I’m working on most is the novel , I will change my preferences in Scrivener so no project comes up automatically
Please let me know if you need more info
Marta
WINXP SERVICE PACK3
Marta – Thank, got the script. I’ll take a look at it and play around to see if I can reproduce the crash and figure out what’s up with that. Good news though is that FDX import/export is coming soon to a Scrivener near you, so that should make all this irrelevant anyway.
Hm, re: the alternate partition/internal drive, it might speed things up to work directly from C:\ alongside the program, so you could test by temporarily moving your novel project to a testing directory there and work on it a bit. I understand though not wanting to change your set up, so this might not be a long-term solution for you. It would still be interesting to know if you see a performance boost if you move your project to somewhere on C:, but whether you want to try is of course up to you.
If changing the auto-save interval didn’t help anything, I’d move it back down to 2 seconds or something low again to make sure you’re getting the frequent saves. What can happen here is that the auto-save triggers just when you’re about to start doing something, causing lag while it tries to save and your action has to wait for that to run, and the effect is heightened when working on a non-local drive (and potentially even on a separate internal drive). Since it didn’t fix anything though, it’s probably more beneficial to have the smaller interval so you’re getting changes saved regularly.
