Bug 79508

Summary: printing with script and mailmerge does not recognize the changed printer
Product: LibreOffice Reporter: mario.edelmann
Component: Printing and PDF exportAssignee: Not Assigned <libreoffice-bugs>
Status: RESOLVED WORKSFORME    
Severity: normal CC: ilmari.lauhakangas, iplaw67, oliver.specht
Priority: medium    
Version: 4.2.4.2 release   
Hardware: x86-64 (AMD64)   
OS: Windows (All)   
Whiteboard:
Crash report or crash signature: Regression By:
Attachments: example print makro

Description mario.edelmann 2014-06-01 16:55:57 UTC
Created attachment 100238 [details]
example print makro

- create a database
- create a text-document with fields from the database
- create a basic-script to print via mailmerge to the selected pinter like attachment

the lines to change the printer
    Dim myPrinter(0) as new com.sun.star.beans.PropertyValue
    myPrinter(0).Name = "Name"
    myPrinter(0).Value = "canon" 'not the standart printer
    oMailMerge.Model.setPrinter(myPrinter)
are not observed. It allways print to the standard printer
Comment 1 Alex Thurgood 2015-01-03 17:41:07 UTC Comment hidden (no-value)
Comment 2 mario.edelmann 2015-01-03 18:07:52 UTC Comment hidden (off-topic)
Comment 3 Alex Thurgood 2015-01-03 18:10:54 UTC Comment hidden (off-topic)
Comment 4 Oliver Specht (CIB) 2015-09-07 12:08:33 UTC
Setting the printer at the model seems to be the wrong way. The model used here is later replaced by the one loaded from 
    oMailMerge.DocumentURL = ConvertToUrl("D:\APPROACH\test.odt")
     
There's a property "PrintOptions" at the mail merge service to achieve the expected result.

Instead of 
    oMailMerge.Model.setPrinter(myPrinter)
it should be 
    oMailMerge.PrintOptions = myPrinter
Comment 5 Buovjaga 2015-09-15 16:51:14 UTC
Mario: did comment 4 solve it for you?

Set to NEEDINFO.
Change back to UNCONFIRMED, if the problem persists. Change to RESOLVED INVALID, if the problem got solved.
Comment 6 Alex Thurgood 2016-06-15 08:05:50 UTC
We can look at this two ways :

- either as WFM because Oliver has proposed a workaround

- or else as a bug in the implementation of the mailmerge API which allows a printer model to be set programmatically, and then doesn't respect that choice, instead overriding it with that taken from a document (which is the default system printer by default)

I would be inclined to close this as WFM with Oliver's solution, and then if the OP feels it important enough, have him open a new bug report with regard to the API.