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.
Related
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.
I have a bunch of Word templates that merge data from a SQL database. What I would like to do is have a signature line on these documents based upon the user that is merging them. For example...If Jeremy Hammond is merging the document, then the signature would be his. If I'm merging the document, then it would be mine. It is not an ACTUAL signature, just a Brush Script font of the name. Actual signatures might come later, but for now, this would do.
Is this possible?
Which version of Word are we dealing with?
If you insert a UserName field into the document (Insert/Text/Quick Parts) and format it with Brush Script, then EXECUTE the merge (not just print the main merge document) does that give the result you're looking for?
If you proceed to the "actual signatures" stage and you store them as graphic images in a folder, then it should/could (depending on version of Word) work to embed the UserName field in the path information of an IncludePicture field.
I have a mail merge template, which includes a bunch of information about the entity that it is associated with in CRM. However, I'm needing a way to add all of the child records from my main entity in to the mail merge template as well.
Is there a way to have a sub record set inside a template?
The easiest solution might be Invantive Composition by inserting a <invantive:foreach>...</invantive:foreach> or through insert building block in the ribbon (note that I work there, but there is also a free version). Alternative solution I've used in the past are programming it completely (using RTF generation outside of Word or VBA or VSTO in Word). But this is quite hard to get right for tables. When the amount of sub records is somewhat limited, you might use PIVOT (see this for example) to change it all into one big record and insert the fields in your document. In the document you may need to hide all placeholders for the sub records not present in a specific instance.
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