We've had these few lines of code running happily in our applications for several years (and in several versions of Office, 2003, 2007, 2010 etc). Purpose is to perform a kind of a mail merge in a Word document, substituting the field placeholders with names, addresses etc from a database:
Dim w As Word.Application
Dim d As Microsoft.Office.Interop.Word.Document = Nothing
...
Dim f As Microsoft.Office.Interop.Word.Field
For Each f In d.Fields
f.Select()
If fieldName = w.Selection.Text Then
f.Result.Text = value
End If
Next
However a user running Office 2013 reports this error on the line f.Result.Text = value
:
System.Runtime.InteropServices.COMException (0x800A17EC): You are not allowed to edit this selection because it is protected.
So, this is only happening when the user is running Office 2013 and there's very little online help for this error.
No part of the document is protected, and the user can edit the document directly in Word without any problem.
For me, the issue was similar to Tim Dols answer, but I needed to unlock the content of the content control., which is the
LockContents
property:mycontentcontrol.LockContents = False
For @CrazyIvan1974, the problem with that solution is that Add creates a new document. if you point at an existing document when using Add, it doesn't load the document, it creates a new document using the original as a template. That can disconnect templates and add-ins, really messing you up if you save over the original
When you open a document, specify that it should not be opened as read-only
In my case, this error was caused by the presence of content controls with
.LockContentControl == true
.To work around this issue, I built an
IEnumerable<ContentControl>
of the content controls with this property set to true, and set.LockContentControl = false
. Now I can.InsertColumnsRight()
without a problem. Then I restore the.LockContentControl = true
for all content controls in my collection.You don't specify how the document is opened, but a problem I had was resolved by following the answer accepted on this question.
Switching from
WordApplication.Documents.Open()
toWordApplication.Documents.Add()
resolved the issue for my application.This has been happening to me for the past two days (while creating a dotm template) and what fixed it for me was to create a new normal.dotx! Don't know if that will work for others or not, but it did for me!
In desperation, trawling for answers even in blog posts and discussions far removed from this particular error it seems there's been a change in Office 2013 to the default treatment of the ReadingLayout.
Introducing the line
w.ActiveWindow.View.ReadingLayout = False
seems to have solved our problem.