This will alsoĪlways be the case with about a dozen controls immediately ahead of the control I've worked on. But what gets saved is corrupt when the document is reopened, the control I added or modified has lost the "Click here to enter text." string and instead shows 5 spaces.
Then, addingĪnother plain text content control, or amending the properties of anĮxisting one, looks correct as I do it. Now, my document works correctly up to a certain size (which I can't specifically identify). Interestingly, there is not always a one-to-one correspondanceīetween controls and doc parts sometimes there are fewer doc parts, which suggests that Word is sometimes doing a "string folding" type operation to compact the glossary. If you look in the w:glossaryDocument, you find a whole load of w:docPart elements drill down into w:docPartBody for these and you find a w:r element that defines "Click here to enter text."Įach control instance has a w:sdtPr element whose w:placeholder element refers to one of those doc parts, so the instance is implementing the default by explicitly referring to a stored string. These do indeed show "Click here to enter text." as their placeholder strings, as you would expect. I start with my document with the tables laid out, and I create a lot of plain text content controls. Let me put some more detail in to show you what I'm meaning. Are you sure you're not mixing content controls and formfields? Text content controls default to 'Click here to enter text'. I could indicate the place people type by delimiting the space-filled placeholder with "", perhaps, but if the document structure is unstable people may not be able to use it properly anyway.ĭoes anyone have any insight? I'd suspect a bug in writing the w:glossaryDocument element.Ĭontent controls don't have a 5-space default, but text formfields do. It does seem likely to be a plain Word bug here - does anyone have any insight? Sadly, I don't think I can do what I want to do in this way, though. I can't pin down an exact scenario that will reliably force the problem to occur, though. I've put a couple of thousand plain text content controls into documents with and without tables with no problems. It doesn't seem to be simply a capacity issue. Mostly, the controls whose placeholders have disappeared have a w:placeHolder element containing a doc part reference to the default string, but not always. The same between saves - sometimes it's one per control, sometimes many fewer. Looking at the document structure with the Open XML SDK V2 Productivity Tool, and with the C# apps I wrote to extract the control details and contents, I see funny things going on with the w:docPart elements in w:glossaryDocument. Have lost their placeholder texts and are showing the default of 5 spaces. Then I see that the control I altered, and around a dozen before it,
Beyond this, a change to the custom controls - adding one or changing properties - looks fine until the document is re-opened. Now, I can get the document to a certain size and it works. I have a couple of drop down list controls too. These have titles and tags defined, are marked as "control cannot be deleted", and are set for multiline input.Ī few cells contain a handful of check box controls (with titles and tags, and marked "not deletable").Ī few cells are split into sub cells with a mixture of these. In most of the table cells I have one single plain text content control. In the document I have half a dozen tables of 3 columns and about 6 rows each. I'll then read out the results with a custom C# app that knows the structure and meaning. I'm intending to use the document for a survey with people checking boxes and typing into text controls.
#Define placeholder text in word 64 Bit#
5000, patched up to date on Windows 7 Enterprise 64 bit SP1) I have a frustrating Word 2010 document that is spontaneously corrupting some content controls.
0 kommentar(er)
