none
Turn Off Document Recovery RRS feed

  • Question

  • I would like to be able to turn off Word 2007's Document Recovery.  If I create a document, save it, make some changes, kill the winword.exe process and restart Word, it opens with the Document Recovery pane showing.  How can I stop this happening?  I have already unchecked the 'Save AutoRecovery information option'.
    Tuesday, October 11, 2011 3:00 PM

Answers

  • Hi Jon

    <<The difference in behaviour between Word 97 and Word 2007 can be replicated without using any code.  After killing the Word 97 process using Task Manager, Word restarts normally.  Is there any option or registry key that could be used to prevent Word 2007 offering to recover the document that was running?  I’m not in the habit of crashing cars but I do believe that newer vehicles should be able to withstand collisions at least as robustly as earlier models :-)>>

    Actually, I don't think that's the case :-) Older cars had metal bumpers, were pretty much all steel (and heavier, requiring more fuel to move them) and could be fixed with "baling wire and tape". Most newer vehicles (of the same type) aren't as tough as the old models and much trickier to fix, due to different materials (lighter-weight) and electronics. (Note that I'm not talking about urban tanks (SUVs), which didn't exist 20 or more years ago.)

    Anyway, back to the matter at hand. Similar to the car analogy, how Word functions internally has been changed over the past ten or more years. A common problem with Word 97 (and all earlier as well as some later versions - and I know whereof I speak as I've been working with it for almost twenty years) was losing your work because "something" happened. Word would crash due to a memory leak, or a "bad" addin, or a damaged document or template... If a user wasn't in the habit of saving every few minutes, a lot of time and effort would be lost. This was one of the big complaints about Word and Microsoft invested a lot of resources to improve its stability. Word crashes less often, and thanks to Recovery much less is lost in case there is a crash.

    The difference in behavior you're seeing is due to these efforts to improve Word for the end-user. Word's main job is to help the end-user, not the developer. These days, if you want to create Word files, the "right" thing to do is generate an Open XML file without even using Word.

    As far as I know, there is no option or registry entry that will turn off document recovery. If there is, the folks in the TechNet forums might know what it is.

    But as long as you're reprogramming the old app I have difficulty understanding why you wouldn't want to bring it up to standards and have it behave correctly. Timewise, I'm sure you've already spent more effort pursuing this than writing a single line of code would have cost you (documentobject.Close(), which, while incomplete would probably still let you "kill" Word without triggering Recovery). 

    Even back in the Word 97 days, doing what this app is doing was "wrong", although it may have served the purpose. Microsoft works a lot to maintain backwards compatibility, but not for solutions that use "undocumented" methods to achieve a goal. Those are unsupported and a developer uses them at his own risk.


    Cindy Meister, VSTO/Word MVP
    • Marked as answer by OfficeJon Thursday, October 13, 2011 1:15 PM
    Wednesday, October 12, 2011 1:38 PM
    Moderator

All replies

  • Hi Jon

    <<How can I stop this happening?>>

    Don't kill the process. That's sort of like driving your car into a wall then expecting it to continue running smoothly. Use the brakes and turn off the ignition, instead :-)

    Make your changes, save the document, close it, then quit Word.

    Since you're posting on MSDN and not Answers I'm assuming you're using programming code for this. If you feel you're already doing what I suggest, please show us the code?


    Cindy Meister, VSTO/Word MVP
    Tuesday, October 11, 2011 3:39 PM
    Moderator
  • Hi Jon,

    I agree with Cindy and yet I know there are times when people feel they must still do it their way. 

    The command is:

    wApp.Options.SaveInterval = 0

    That suspends the autorecovery function.


    Kind Regards, Rich ... http://greatcirclelearning.com
    Wednesday, October 12, 2011 2:16 AM
  • Hi Cindy,


    Programming code is being used to kill the Word process.  I am working on a VB.NET/Word 2007 application that is a rewrite of an existing VB6/Word 97 one.  I agree that killing the process is not the proper way to close Word but the existing app gets away with it without Word 97 asking about recovering the documents that were running.


    The difference in behaviour between Word 97 and Word 2007 can be replicated without using any code.  After killing the Word 97 process using Task Manager, Word restarts normally.  Is there any option or registry key that could be used to prevent Word 2007 offering to recover the document that was running?  I’m not in the habit of crashing cars but I do believe that newer vehicles should be able to withstand collisions at least as robustly as earlier models :-)

    Wednesday, October 12, 2011 1:08 PM
  • Hi Rich,


    Thanks for your reply but it does not prevent Word 2007 asking afterwards whether I wanted to recover the document, so I guess wApp.Options.SaveInterval = 0 is just equivalent to unchecking the 'Save AutoRecovery information' option.

    Wednesday, October 12, 2011 1:10 PM
  • Hi Jon

    <<The difference in behaviour between Word 97 and Word 2007 can be replicated without using any code.  After killing the Word 97 process using Task Manager, Word restarts normally.  Is there any option or registry key that could be used to prevent Word 2007 offering to recover the document that was running?  I’m not in the habit of crashing cars but I do believe that newer vehicles should be able to withstand collisions at least as robustly as earlier models :-)>>

    Actually, I don't think that's the case :-) Older cars had metal bumpers, were pretty much all steel (and heavier, requiring more fuel to move them) and could be fixed with "baling wire and tape". Most newer vehicles (of the same type) aren't as tough as the old models and much trickier to fix, due to different materials (lighter-weight) and electronics. (Note that I'm not talking about urban tanks (SUVs), which didn't exist 20 or more years ago.)

    Anyway, back to the matter at hand. Similar to the car analogy, how Word functions internally has been changed over the past ten or more years. A common problem with Word 97 (and all earlier as well as some later versions - and I know whereof I speak as I've been working with it for almost twenty years) was losing your work because "something" happened. Word would crash due to a memory leak, or a "bad" addin, or a damaged document or template... If a user wasn't in the habit of saving every few minutes, a lot of time and effort would be lost. This was one of the big complaints about Word and Microsoft invested a lot of resources to improve its stability. Word crashes less often, and thanks to Recovery much less is lost in case there is a crash.

    The difference in behavior you're seeing is due to these efforts to improve Word for the end-user. Word's main job is to help the end-user, not the developer. These days, if you want to create Word files, the "right" thing to do is generate an Open XML file without even using Word.

    As far as I know, there is no option or registry entry that will turn off document recovery. If there is, the folks in the TechNet forums might know what it is.

    But as long as you're reprogramming the old app I have difficulty understanding why you wouldn't want to bring it up to standards and have it behave correctly. Timewise, I'm sure you've already spent more effort pursuing this than writing a single line of code would have cost you (documentobject.Close(), which, while incomplete would probably still let you "kill" Word without triggering Recovery). 

    Even back in the Word 97 days, doing what this app is doing was "wrong", although it may have served the purpose. Microsoft works a lot to maintain backwards compatibility, but not for solutions that use "undocumented" methods to achieve a goal. Those are unsupported and a developer uses them at his own risk.


    Cindy Meister, VSTO/Word MVP
    • Marked as answer by OfficeJon Thursday, October 13, 2011 1:15 PM
    Wednesday, October 12, 2011 1:38 PM
    Moderator