I am creating an automation solution for Word (2007). Sometimes I have to kill the Word process. Next time word is launched a tab/window appears suggesting to recover an unsaved document. I would like to either disable this or have my application close this window.
I have no idea where the entry point to this tab/window is.
EDIT: I've found out that word calls this "Feature" Repair, not Recover. Still no idea how to avoid/bypass/disable it.
Suggestions?
This can be solved by deleting the Resiliency key in the Registry before starting Word again. This is described here:
Every other time that you open a document in Word, the document opens in recovery mode or you receive an error message
You can safely delete the entire Resilience key for local machine and the current user. Note that there are various places where the key is stored:
HKEY_CURRENT_USER\Software\Microsoft\Office\\Word\Resiliency
HKEY_LOCAL_MACHINE\Software\Microsoft\Office\\Word\Resiliency
HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\Terminal Server\Install\Software\Microsoft\Office\\Word\Resiliency
I assume you have access to the word:
http://www.ehow.com/how_6012331_disable-document-recovery-word.html
[edit]
Seems this doesn't work, you could try
Options.SaveInterval = 0
(source: http://www.tech-archive.net/Archive/Word/microsoft.public.word.customization.menustoolbars/2004-07/0195.html)
but I assume this gives the same effect as what I said first.
[/edit]
Its not possible atm. Maybe on next SP...
Related
We are developing a COM Add-In for Microsoft Word (only local, not for cloud usage). One of our customers had the problem, that each time he started Word, he had to manually activate the Add-In (Word Options > Add-Ins > Go... > tick the checkbox for the corresponding Add-In). I could reproduce this behavior by forcing an error in the Add-In coding which caused Word to crash. When starting Word the next time, I got the following message:
Of course I saw this message several times before. But: back then the consequence of clicking on "Yes" was that the Add-In was disabled. In that case it was sufficient to re-enable it one time (as described above). The next time the Add-In was started, you didn't have to enable it any more.
But now, additionally to disabling the Add-In, there is a registry key created. That key has the name of the Add-In and is located at the following path: HKEY_CURRENT_USER/SOFTWARE/Microsoft/Office/15.0/Word/AddInLoadTimes.
And it seems that this key causes the behavior described at the beginning. Because if I delete the key, start Word, enable the Add-In, close word, set the "LoadBehavior" key in the registry to "3" and then restart word, everything is fine again.
Now my question: is there a user-friendly alternative to enable the Add-In? Since the fewest of our users have administrative privileges, we cannot ask them to change some registry keys in order to fix the problem.
I hope that someone can help me with this.
Best regards
Timo
The path we took to avoid this issue, was to check in the code any static initialize methods / properties (which are invoked when word tries to activates the addin), which potentially could throw exceptions (IO work, REST api requests ... etc) and added to them try / catch blogs with some notification to the user that the activation of the addin failed + logging of the exception.
Side Note: At the time we have struggled the same issue we could not find anything but the registry key which you have mention to resolve this behaviour, but we faced the same security restriction, so this was not an option.
Not knowing much about your add-in, I can think of 2 possibilities:
Since the registry key is in HKCU (which is normally fairly accessible) why not create a 2nd 'helper add-in' that checks for problems with this key and resets it when required?
Otherwise you could use Inno Setup to create a dummy installer that does this for you?
I think this is possible because your target location is HKEY_CURRENT_USER/SOFTWARE/Microsoft/Office/15.0/Word/AddInLoadTimes (i.e. HKCU) which usually can be modified without admin rights: Changing registry without admin rights
Solution seems to go to Options > AddIns, then click GO aside Word Add-ins:
Then select desired one and click ENABLE/DISABLE.
I am using Word (from 2007 to 2013) to convert documents to PDFA format,
and i'm having trouble with users who have certain add-ins. When they use the system they get an assortment of COM Exceptions like RPC_E_SERVERCALL_RETRYLATER and (0x800706BA) RPC server unavailable.
If they disable the add-ins it works fine. Problem is that the add-ins are required so that simple solution is out the window. (Also I know that using word for this kind of thing is frowned upon, and we are looking into getting something better, but until the business side want's to pay, we are stuck with this)
The new plan is to start word with the /a parameter to make it start without add-ins.
I have seen another question How can I start MS Office Word from .NET without Add-ins?
Where there is a working solution for one instance of Word,
//startup without plugins
System.Diagnostics.Process.Start(
#"Winword.exe",
#"/a");
//give a time for startup
Thread.Sleep(2000);
//attach to office
Application officeApplication = (Application)Marshal.GetActiveObject("Word.Application");
My question is two fold: Is it possible to set startup parameters when you start word like this
var _word = new Word.Application();
So I don't have to use Process.start();
And if not, how do I do a late bind to a specific word instance (GetActiveObject(), always gets the oldest word instance), perhaps there is some other method?
To your first question, there's no way to pass parameters or otherwise influence how Word starts when using the new keyword. The instructions for starting the application are in the Registry, so it would involve changing how the new keyword is implemented in the Registry. And since this Registry entry also determines how Windows Explorer starts the Word.Application, changing the Registry entry would also change the way Word works for the user.
It is possible to unload add-ins after an instance of Word has started via the Application.COMAddins property. This is the equivalent of unchecking the boxes next to the Add-in entries in the COM Add-ins dialog box in the Word UI. I would test whether doing this in the UI allows your software to work properly.
If it does, you can incorporate this in your code - no need to worry about starting Word without the add-ins.
Which brings us to the second question: GetActiveObject is only able to access the single instance of Word (any Office application) registered in the ROT. By design, Office applications register only a single instance in the ROT and usually, this will be the first instance. There are a couple of KB articles on MSDN that describe this. The only work-around is to start two instances of Word in the user profile, "hiding" the first (the registered) one and presenting the second to the user.
But this can be tricky, so if it works, I'd go with the suggestion about the COMAddins collection to unload the problem Add-ins.
(I'm currently on a mobile device. Next time I'm on my main machine I'll try to remember to paste in the links to the KB articles on the ROT.)
This happens with the Emulator as well as with the real device, in Debug-Mode as well as in Release-Mode.
In the app I store several application settings successfully - from simple value types to more complex objects and lists of objects.
With "WP POWER TOOLS" I can track the file "__ApplicationSettings" in the root of the IsolatedStorage. It is "well filled" - in the first lines I find some classes and assemblies, that define the complex type definitions, and below the XML starts with the <ArrayOfKeyValueOfstringanyType...>
So, everything looks normal to me so far.
When I close my app, the last piece of running code is the "Application_Closing"-Handler in App.xaml.cs. In this moment I can check the ApplicationSettings the last time - everything is okay.
For example: I check the count of the entries:
var count = System.IO.IsolatedStorage.IsolatedStorageSettings.ApplicationSettings.Count;
...and the count is right and the keys/values are right.
Then - I restart the app at once (Visual-Studio-Debugging is not interrupted) and the first piece of running code is the ctor App() in App.xaml.cs.
In the first line I check the count of ApplicationSettings-Entries again, and: it is 0 !!!
But: WP POWER TOOLS still show me, that the "__ApplicationSettings"-File is existing and is still filled like before.
(The consequence of this error is afterwards, that with the first attempt to save any setting again, the whole __ApplicationSettings-File is overwritten and contains just the one new setting.)
So what could be preventing the App from "using" the existing "__ApplicationSettings"-File???
Thanks in advance!
(PS 1: I already experienced, that all ApplicationSettings are destroyed, when there happens an Exception while saving the settings. I investigated all of that already and are 99.9% sure, that there is no Exception anymore.)
(PS 2: Just to make it clear: It is NOT the case, that the complete IsolatedStorage is gone. I have also another file for logging purposes, that I write to the root of the IsolatedStorage. This file is always there. Also the __ApplicationSettings file is not "deleted", it just seems, that the app doesn´t "read" it when launching.)
I tried the repro scenario with an app of mine and confirmed what I expected, that IsolatedStorageSettings.ApplicationSettings.Count was nonzero on entry to the App() ctor upon running the app for a second time in the same emulator process. So there is hope for you to get to this desired state too!
Since you report that the _ApplicationSettings file is not empty, I'll guess 2 possibilities: Maybe an app (or some other process?) keeps the _ApplicationSettings file open when the 2nd run of the app is trying to open the file for reading? MSFT doesn't document how the read is done, so maybe the file is opened with FileShare.None, or with FileShare.Read but some other process still has the file open for writing? I have no idea how to test this on the emulator, but on the real device you might try this scenario:
Run the app for the first time, verify it saves a non-empty _ApplicationSettings.
Restart the phone device (debugger will disconnect)
Run the app for the second time, with a breakpoint in App() ctor.
After 2) I would be confident no other process could have the file open, so the app should be able to read its contents without interference. But if you discover that it still has zero count in 3), then another possibility exists:
Maybe the restarted app encounters an error trying to deserialize the settings from the file into your data structure(s)? The error might not prevent the data from being serialized when the first run of the app is exiting.
To check this possibility, first look for error messages in the Output, Debug window. Do you see any errors when restarting the app the a second time?
If you don't see any helpful error messages, the next thing to try is to simplify the data structures being saved as settings. Try cutting down to just one setting that is a simple type like an int or string. See whether that can be restored correctly, then add more of your settings back into the file until you home in on the one which causes a problem.
Do you call Save on settings? Does it throw any error?
I'm trying to do some changes to the properties of the documents that users edit in a Sharepoint 2010 Document Library progammatically using an Event Handler. At the moment, I'm trying with the event ItemCheckedIn. The problem comes when I execute the following instruction:
item.File.Update();
It gives me an exception saying that the document is locked by user XXX.
Am I updating the properties in the wrong event? How can I avoid this exception?
Thank you in advance.
Try using
item.SystemUpdate()
instead
Microsoft Office Word is issuing a lock request on documents by default and it is different than 'Checked Out' state.
'Lock' is release only after document is closed by Word. While 'Check Out' can be performed via Word or web interface and it would remain such until explicitly requested to 'Check In'.
As previous comment suggest, the best remedy is to to use in your code:
item.SystemUpdate(false) as that would not obey to 'Lock' state and save any changes done via Event handler code.
For example,
I have an excutable TrashClean.exe running. I want it to delete all files I don't want and also delete itself (TrashClean.exe on hard drive) at last step.
I am wondering if it's possible in C#?
Please see How To Make Your Application Delete Itself Immediately:
I'm sure you've all said to yourself
or someone at the office at one point
or another, "<snort> You idiot. Don't
you know a Windows application can't
delete itself? I bet you don't even
know how to type high ASCII characters
using the ALT key and the number pad,
gahhhh.."
Sure, there are ways to have a file
delete itself on the next reboot...
And you can even resort to an external
program or batch file to do the work.
But I just came up with a nifty way of
doing it without leaving a visible
trace that the application ever
existed!