<html> <head> <base href="https://bugs.documentfoundation.org/"> </head> <body> <div> <a class="bz_bug_link bz_status_NEW " title="NEW - Mail merge does not change the merge fields in files (when saved as individual documents) to plain text" href="https://bugs.documentfoundation.org/show_bug.cgi?id=89178#c25">Comment # 25</a> on <a class="bz_bug_link bz_status_NEW " title="NEW - Mail merge does not change the merge fields in files (when saved as individual documents) to plain text" href="https://bugs.documentfoundation.org/show_bug.cgi?id=89178">bug 89178</a> from <a class="email" href="mailto:glogow@fbihome.de" title="Jan-Marek Glogowski <glogow@fbihome.de>"> Jan-Marek Glogowski</a> <pre>(In reply to Ben Fleming from <a href="show_bug.cgi?id=89178#c24">comment #24</a>) > (In reply to Jan-Marek Glogowski from <a href="show_bug.cgi?id=89178#c23">comment #23</a>) > Thank you very much for your reply, it was really interesting to have the > insight from someone who knows the code. > > So if I understand you correctly, the MM process merely produces one doc > with bookmarks and then it splits that document into individual files. No. My description is just the MM wizard behavior and describes, why you see differences between the wizard and UNO / your BASIC macro. I just had to check the source code. LO MM wizard generates a document shell and a list of bookmarks, which point into the document (see SwMailMergeConfigItem and SwDocMergeInfo). I suggest to use <a href="https://opengrok.libreoffice.org/">https://opengrok.libreoffice.org/</a> to display the C++ definitions. There is also a README in <a href="https://opengrok.libreoffice.org/xref/core/sw/source/uibase/dbui/">https://opengrok.libreoffice.org/xref/core/sw/source/uibase/dbui/</a>. It describes the MM behavior based on the members of SwMergeDescriptor, which describes how to process the input. That descriptor also has more comments on its members. Most members will directly match to UNO from what I remember. > Is there any way to replicate this behaviour through the (BASIC) UNO API? > > When I generate a MM to a single document myself manually, I cannot see any > bookmarks. I think so. You need to do a MM of type MailMergeType.SHELL, not a document MailMergeType.FILE. That will generate a LO internal document shell. And it fills a list of SwDocMergeInfo with the UNO bookmarks into the merged document. So the document itself doesn't contain the bookmarks. I know WollMux uses it to implement its MM (if you know Java see <a href="https://github.com/WollMux/WollMux/blob/WollMux_18.2/core/src/main/java/de/muenchen/allg/itd51/wollmux/mailmerge/print/OOoBasedMailMerge.java">https://github.com/WollMux/WollMux/blob/WollMux_18.2/core/src/main/java/de/muenchen/allg/itd51/wollmux/mailmerge/print/OOoBasedMailMerge.java</a>), so that should work with BASIC too. > > This is all very non-obvious from the users POV. > > This is the problem really, I suppose at least the front-end is behaving (at > least in my testing) exactly as expected, although there are a lot of bugs > open to suggest it doesn't for everyone? See <a href="https://bugs.documentfoundation.org/page.cgi?id=weekly-bug-summary.html">https://bugs.documentfoundation.org/page.cgi?id=weekly-bug-summary.html</a>: 12102 open bugs. And LO has probably 30-40 core developers, half of them mainly working on LO Online (that is just a guess). And a few bugs will be for mail merge. Problem is, most features don't have any description of "expected behavior". One persons bug might literally be an other persons feature, and that is not just an XKCD joke (<a href="https://xkcd.com/1172/">https://xkcd.com/1172/</a>). If you have millions of users, there will be enough existing workflows, which expect some behavior, even if it's actually a bug. I broke stuff this way a few times.</pre> </div> <hr> You are receiving this mail because: <ul> <li>You are the assignee for the bug.</li> </ul> </body> </html>