Bug 79508 - printing with script and mailmerge does not recognize the changed printer
Summary: printing with script and mailmerge does not recognize the changed printer
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Printing and PDF export (show other bugs)
(earliest affected) release
Hardware: x86-64 (AMD64) Windows (All)
: medium normal
Assignee: Not Assigned
Depends on:
Reported: 2014-06-01 16:55 UTC by mario.edelmann
Modified: 2016-06-15 08:05 UTC (History)
3 users (show)

See Also:
Crash report or crash signature:

example print makro (932 bytes, text/plain)
2014-06-01 16:55 UTC, mario.edelmann

Note You need to log in before you can comment on or make changes to this bug.
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
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 
it should be 
    oMailMerge.PrintOptions = myPrinter
Comment 5 Buovjaga 2015-09-15 16:51:14 UTC
Mario: did comment 4 solve it for you?

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.