I have an application that:
Copies a file
Pastes the copy with a new name
Modifies it
Saves it
This has been working fine, but then today, I've been getting this error:
Normal was being edited by another Word session. If you save this
document with the original name, you will overwrite any changes made
in the other session. Do you want to save the document using the
original name anyway?
And this is the file location of "Normal.dotm". I've never seen this file and am not manually accessing this file in any of my code.
C:\Documents and Settings\MyUserName\Application
Data\Microsoft\Templates\Normal.dotm
I'm running old code that has worked fine in the past, and I reset my computer, so I don't think any of my processes are screwing this up. What could be causing this? It seems like something happened externally to cause this problem, but I could be wrong. I'm genuinely stumped.
You might get this save message when you edit the styles or margin settings of the document.
Refer this
http://office.microsoft.com/en-us/word-help/change-the-normal-template-normal-dotm-HA010030756.aspx
I suppress this message in my application because we set some settings for Word when the document opens up
foreach (Word.Template template in Globals.ThisAddIn.Application.Templates)
{
switch (template.Name.ToLower())
{
case "normal.dotm":
template.Saved = true;
break;
}
}
I have noticed that if you have outlook opened it locks the normal.dotm file so check if your outlook is editing your normal.dotm file
Related
I have some xml code that i like to have pretty printed (but is not parsable by tools like XmlDocument etc.) in a browser. I currently write the xml code to a file with
File.WriteAllText(filepath, xmlCode);
When i then open the .xml file in file explorer, I get an error that is can't be parsed. No matter if i open it via code or via file explorer.
However when i copy the exact same message into windows text editor and save it as .xml, it is pretty printed regardless of the browser I open it with. This applies to opening it by code and file explorer.
Does c# or editor add some hidden attributes to the file that is not visible to me (but can be manipulated) which could explain this behaviour?
A colleague of mine said it could have something to do with NTFS streams but I know too little about them.
Thanks for the responses!
It turned out to be more simple than encoding issues and more of a problem of how it was formatted before getting to my end.
Someone must have done:
message.Replace(" ", string.empty);
Which resulted in the xmlns:i part being put together with the attribute name (I belive this is called differently but I don't know the proper name), as such
<AttributeNamexmlns:i="....
My solution:
It still is not parcalable for a XmlDocument or similar for some reason (but that is not necessary for me, as long as it is pretty printed), so my current solution is to open it in a browser (specifically a WebBrowser in Windows Forms, but this should work with a "local" browser too):
First I get rid of the spacing mistake (yes this should be done at an earlier stage in the process, this is just temporary):
var index = msg.IndexOf("xmlns:i");
msg = msg.Insert(index, " ");
Then write it to a file and open it in my custom browser (which is nothing more than a WebBrowser in a form - with nothing modified):
CustomBrowser cb = new CustomBrowser();
cb.Show();
cb.Navigate(filePath);
This then pretty prints the xml doc and displays it. (Thats all I need for my use case)
I've developed a customization in Visual Studio for Word 2010 and have the solution saved in network share (using a UNC path) and the actual Word document is saved in a folder in SharePoint.
Everything works fine, users can open the document and use the customisation and when they've gone through the steps the add-on requires they click a button which saves the completed document to a different location in SharePoint. Al good. When you however now open the newly saved document from SharePoint I get the following error message:
Cannot currently access the deployment manifest at this location:
"[URL to document path in SharePoint]". You muyst set the deployment
manifest location to a UNC share or a local path when
ClickOnceAddInDeploymentManager.RunFromFolder is true.
Have done some searches on these terms but getting nothing useful! Would appreciate any help you could offer!
Try this article:
http://msdn.microsoft.com/en-us/library/vstudio/bb772100(v=vs.110).aspx
Particularly the steps under the heading:
To put the document on a server that's running SharePoint
I don't think word trusts your document after you save it in a different location.
I figured out my problem, need to give a bit more background to explain the issue a bit better.
I'm using a number of Action Panes to create a wizard-like experience for the user. When the user hits "Next" on the first pane I have code (using ThisDocument.SaveAs2) so automatically do a Save As to a specific folder in SharePoint (actually the structure gets created on the fly before it being saved).
On the final pane when they hit Finish I was running the exact same code to Save As but to the exact same location and filename and this is what seems to have caused the problem. The bottom line is that the custom property _AssemblyLocation was changed somehow in this process to only have the filename of the vsto file without an absolute path, so on re-opening the document it was looking for this file in same location.
By simply changing this to a Save instead of a Save As it now works perfectly. Took me insane amounts of time to figure that out but my own fault!
I have these lines of code in a loop:
rfmSheet.Cells[i, 18].Formula = String.Format("=VLOOKUP(O{0},[POvsPT.xlsx]Sheet1!$H:$K,4,0)", i);
rfmSheet.Cells[i, 19].Formula = String.Format("=VLOOKUP(P{0},'[PT Vendor.xlsx]Sheet1'!$A:$C,3,0)", i);
Both files are in the same directory and I open them both prior to the execution of the loop.
The first vlookup formula does it's job perfectly but the second one gives a pop-up requesting that I should open the file, although it's already opened. What am I doing wrong here?
EDIT
So after doing more testing it seems that the first file got opened because somehow I saved a copy of it in Documents and it fetched it from there. After deleting it the open dialog appeared.
Is there a way to make the formula see that the file is already opened? I'm really stuck with this...
I'm trying to open a really old (binary) Word-file using C#/.NET and Microsoft.Office.Interop.Word. Whenever I try to open this file using the snippet below, it fails with a COMException telling me that "You are attempting to open a file type that is blocked by your File Block settings in the Trust Center."
This also used to happen when opening the same file in MS Word, but after adjusting the settings found in the Trust Center this now works just fine. However, I still cannot open the file using C#. Does anyone know if VS2010 caches these settings, or use its own settings somewhere? I have also tried to create a new project (after fixing the settings in Word) with the same snippet to see if that helped, but it did not.
Word.Application app;
string file = "<filename>";
app = new Word.Application();
try
{
app.Documents.Open(file);
}
catch (COMException e)
{
string s = e.Message;
}
This is implemented with an alternate data stream, supported by the NTFS file system. You access such a stream with the filename:stream syntax. The stream name that stores the info for the file blocking feature is Zone.Identifier:$DATA. It is written by whatever program copied the file, usually a browser.
You can see them with the DIR /R option. The SysInternals' Streams utility permits listing and deleting them. A silly way to get rid of it is copying it to a file system that doesn't support alternate data streams, like a .zip archive or a flash drive and copying it back.
You can look at the content of the stream or edit it with a command like notepad filename:zone.identifier, you'll see this:
[ZoneTransfer]
ZoneId=3
The ZoneId value identifies the origin of the file. Values are -1=unspecified, 0=local machine, 1=intranet, 2=trusted, 3=internet, 4=untrusted. What notepad can do is however not possible in .NET, it explicitly forbids using the : character in file names. The intention is for a human to deal with this, explicitly overriding the file blocking feature. Right-click the file in Explorer, Properties and click the Unblock button. That deletes the stream. Note the Powershell cmdlets mentioned in the first link.
This is what I'm trying to do :
Download a file (txt, doc, xls, whatever) from a server
Open the file with the appropriate application using System.Diagnostics.Process.Start(path to file)
Monitor for file changes using a FileSystemWatcher.
Each time the file is changed, upload the file back to the server
Continue monitoring until the user has finished editing the file
Delete the local copy of the file
Exit the application
I'm stuck at step 5. How can I know whether a user has finished working on a file ?
I cannot rely on the file being locked (notepad doesn't lock txt files for example).
I cannot rely on a process having exited or not (an example is Notepad++ for txt files : the file could be open in a tab. When you close the tab, you've finished editing the file, but the process is still running)
Any idea/points on how to do that in C# ?
You've excluded the two ways you could go about detecting the file being in use: file locking, and the process you start exiting.
The only alternative I an think of is to display a dialog to ask the user when they've finished editing.
Edit: For what it's worth - FileZilla has this type of behaviour. You can choose to edit a file on the remote server, it downloads the file, launches the default editor, and (in the background) shows a "If you've finished editing - Click OK" button.
This gives me the opportunity to cancel an edit, if I've mucked up the file and saved it.
This is really hard to do - we've tried various things but never found anything that was foolproof. If you know the program you have launched then, in theory, you can find the file handles it uses and see when it stops using the one you're interested in.....but if you rely on Windows to resolve the default application to launch even this becomes tricky.
We copy editable files into a temp folder named with the date and rely on users uploading them back when they have finished their edit session. We then clean up previous days folders on application startup.
You could check the date of last change of the file. This date gets set when you save changes to the file. Mind though that this field is not very reliable since one can set it to any value (with appropriate tools).