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.
Related
Our doc preparation team uses word templates and mail merges them from a database.
However, we would like certain mergefields to be ignored so that they can be processed later from another data source.
In this basic example below the word mail merge wizard doesn't allow me to just ignore the additional field that is not in the datasource (the excel spreadsheet).
Is there a programatic way to "ignore" extranious mergefields? Or even a way to use a regular text placeholder and have it merg-in a mergefield dynamically during mailmerge?
What you are asking is not possible. Even if you were to create dummy fields in your mailmerge data source so the extraneous fields don't generate errors, those same fields will be deleted when the merge is executed.
I am working on my portfolio for grad school and I am having an issue with inserting a word document into another and keeping the original formatting of both. I built the main document so that all I would need to do is insert my supporting documentation which has to be of a different format. I tried next page section breaks and it generates the next page but all the formatting is still tied to the main document. Thanks in advance.
Just make a regular copy and paste. Control+C on source and Control+V on destiny. Best.
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.
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 have created a Word document with Word 2003 and inserted some MergeField via the GUI.
I have saved it as a .docx by using Microsoft Office Compatibility Pack for Word, Excel, and PowerPoint 2007 File Formats. Some Mergefields are stored as a SimpleField, while others are stored as a FieldCode (with start-FieldChar and end-FieldChar). Some Googling brought me to this blog. As you can see the guy is facing the same problem; but hasn't found a solution yet.
I'm using the following code sample on Codeplex [Fill Mergefields] to replace the MergeFields with the actual values from different datasources.
Any help is welcome.
If a field's value is just simple text with consistent formatting, it can be stored as a fldSimple node. However, if the field's value has varying formatting, it has to be saved as a complex field (fldChar Start, Optional Separate, and End) so that each run within the field's value can have it's different formatting defined in the run properties <w:rPr>. I think that also happens if word uses the rsid attributes to track changes. The fldChar Start/Separate/End are also necessary if the fields are nested, such as multiple IF fields, so that it can store an arbitrary number of <w:r>, <w:p>, <w:tbl> as the field's value.
And sometimes it stores them like that for seemingly no good reason. (As that blog noted).