I'm wondering if there is a way to get Embedded Word Documents to have access to the Main Document's MergeFields. We are in the Real Estate Business and Typically use MEGADOCS basically a huge word file that has multiple documents. It's a hassle making changes to the documents since it has to be changed in all our documents for the different states we do business in. I was trying to explore using Embedded documents that way I can make the change once and it propagate to all the documents that contain that embedded document. However it has MergeFields in it that needs to be updated when the Main document gets ran from our software.
Current way I've tried doing it is "INSERT/Object/Object..." Create from File with the Link to File flag checked. However this simply puts what appears to be an image of the actual document not the actual document itself (and the mergefields haven't been processed).
Any assistance would be greatly appreciated.
Here is a image of what I get when I try running the Embedded document in the main document with MergeData.
Mailmerge fields in a document embedded in a mailmerge main document will not be processed by a mailmerge. However, mailmerge fields in a document linked via an INCLUDTETEXT field, such as Word generates when you use Insert|Object>Text from File, with the Link to File option will be processed by a mailmerge; the only provisos being that the linked document is not itself a mailmerge main document and that the fields it employs appear in the data source used by the parent mailmerge main document.
Related
Is it possible to create a dynamic document derived from a second document? For example a student document that contains problems, and then a teacher's version which has the exact same contents as the student one, but has additional paragraphs with discussion points and solutions.
The dynamic part is important so that if changes are made to a problem in one document the other gets updated.
Perhaps using hidden text and only copying the non-hidden parts to the second document?
I'm performing a mailmerge via a VB app joining data from a CSV to an existing Word (2010) main document which contains some macros. When the merge is completed I display the merged doc with the data and the customer wants to run some of the macros that were in the main document against the merged document.
However, the macros from the main document don't exist in the merged document and I'm wondering if there is some way I can get them to come along for the ride.
(I do save the merged document before displaying to the user, so maybe the Save is causing me to lose them?)
Correct - the macros are not copied. If they were, you can imagine that an enormous maintenance problem could be created as every single merge document created would have a copy of the macros, not a pointer to them.
Typically, you have to put the macros in a template, and ensure that the mail merge main document is attached to the template (which will be the case if you create a new mail merge main document from the template, for example).
But when you do that neither auto macros such as autoopen and autonew, now the equivalent Document Events will run automatically when the mail merge output document is created or completed.
Also, ISTR that there is a problem where the macros may not be visible/usable until you have saved the output document (and possiby closed/re-opened it). I forget exactly what goes wrong.
If you really do need to copy the macros into the output document, I think you would be better off storing them in a .bas file outside any Word document, and you may be able to use the VB Extensibility library to load them into the output document.
Plenty of information is being stored in Enterprise Architect as linked documents. Is there a way to search content contained in these documents?
In the GUI, the only way to do this is to open the document and search inside it, which I assume is not what you're after.
I don't think an in-EA SQL search would get this done either. The linked documents are in RTF, so you'd have to parse that to find the text you're looking for.
But you could do it with a script or an Add-In.
The Object Model API method Element.GetLinkedDocument() returns the RTF contents from an element's linked document. Then, you can use Repository.GetFieldFromFormat() and Repository.GetFormatFromField() to convert that to plain text.
I would like to embed one Word document (call it "hidden.docx") into another Word document (call it "host.docx"). The document hidden.docx would not be visible at all when host.docx is opened in Word by an end-user. Document hidden.docx would only be carried inside host.docx, sort of as unstructured cargo data.
All research I have done points me to the use of something called altChunk offered by the Open XML SDK. I have installed Open XML SDK and got a sample working: http://msdn.microsoft.com/en-us/library/gg490656%28v=office.14%29.aspx
My question: In order to insert an altChunk into a docx, do I really need the Open XML SDK? Can this not be accomplished using VSTO? If so, how?
[PS: My ultimate goal is, for a pair of documents where one document is the original text and the other is its translated version in another language, to be able to preserve the original document within the translated document, so as not to lose it. For any document pair, there's always the risk that the two documents become separated through misplacement of one of them.]
Yes and No.
1.) That's not what AltChunks do. AltChunks are a way to embed one document into another document such that they get merged together. They are not hidden. If you create a docx package with an AltChunk in it, and then open up Word, Word will immediately merge that AltChunk into the document. (If that AltChunk is another Word document that also contains child AltChunks they will be recursively merged into the parent as well.) Basically, it's an easy way to merge content together without having to reconsolidate all their styles, rIDs, etc. -- if you save the document and examine it, the AltChunk will be gone, and you will notice that Word has merged the document back together into a single document again.
2.) Range.InsertXML, if provided a valid Flat Package for a full Word document will, under the hood, invoke that same merge functionality (down to having the same bugs, etc.) that you would get from an AltChunk. The two behave identical, and you can even create a document package with the OpenXML SDK that contains embedded AltChunks, and insert those (I've done this in Word 2007, 2010, and 2013) -- of course, as I mentioned above, the AltChunks are never persisted, they're immediately merged into the document.
If you want to save hidden data in a document, I recommend using Custom XML (take a look at Document.CustomXMLParts). Keep in mind though, at least in Word 2010, Undo does not revert changes to CustomXML parts.
If you simply want to include some file into the Open XML package, then the simplest way is to use API from the System.IO.Packaging namespace (First obtain the reference to the main document part of the host part):
EmbeddedPackagePart hiddenDocumentPart = mainDocumentPart.AddEmbeddedPackagePart(#"application/vnd.openxmlformats-officedocument.wordprocessingml.document");
hiddenDocumentPart.FeedData(File.Open(hiddenDocumentFile, FileMode.Open));
Just to be sure, this way the hidden document will be in no way part of the host document content. It will only be part of its file (package). You can later extract it with a similar method: Get the main part of the host document, find the embedded (hidden) part and get/read the data from it.
I am using Open XML SDK and altchunk to merge multiple documents in a winforms application, after merging I want to manipulate paragraphs, the problem that until a document that contains altChunk elements is opened and saved in Office, it still contains the altChunk parts, and not normal WordprocessingML markup of paragraphs, runs, and text elements. So I need to proceed to chunk importation to get the WordprocessingMl and to be able to manipulate paragraphs, runs, texts... The solution with SharePoint 2010 is that you can use Word Automation Services to update the documents that contains altChunk elements. After Word Automation Services processes it, the document will contain paragraphs, runs, and text elements, but here I am using winforms application. Is there a solution for this problem?
Regards.
An altChunk approach to merging word documents relies on the consuming application (the application which opens the resulting document) to do the actual merging, like Word or Word Automation Services.
See: http://blogs.msdn.com/b/ericwhite/archive/2009/04/19/comparison-of-altchunk-to-the-documentbuilder-class.aspx
I don't think you will be able to reference the runs, paragraphs etc of the inserted document (altChunk) using the OpenXML API until this merging has been done. Maybe if you open the altChunk data and load that into a new WordprocessingDocument. But then maybe you could just make the changes to the documents before you merge them with altChunks?
As a workaround, I make copies for the merged documents, I proceed the changes on this copies, when the merged document is opened the altchunks are imported, in this way I keep the original merged documents content unchanged