https://bugs.documentfoundation.org/show_bug.cgi?id=156839
Stéphane Guillou (stragu) <[email protected]> changed: What |Removed |Added ---------------------------------------------------------------------------- Blocks| |127592 CC| |stephane.guillou@libreoffic | |e.org Status|UNCONFIRMED |NEEDINFO Ever confirmed|0 |1 Whiteboard| QA:needsComment | --- Comment #3 from Stéphane Guillou (stragu) <[email protected]> --- Tested with CUPS' print to pdf printer-driver-cups-pdf, set as default printer via File > Printer Settings...; which will output by default in ~/PDF. Reproduced that I'm getting two separate files without the content's of the second sheet: one page of sheet 1's contents, one empty page. Version: 24.2.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: beaea2e992912b4747d790070b26371f557b1f57 CPU threads: 8; OS: Linux 5.15; UI render: default; VCL: gtk3 Locale: en-AU (en_AU.UTF-8); UI: en-US Calc: threaded In OOo 3.3, I also get just the first sheet, but no emtpy second document. So is this really a regression? 0b793116deaf35ce67245c1106e5ed5a722c7560 made it possible to export the second empty sheet, but it must have been considered to be empty before that. (In reply to Gabor Kelemen (allotropia) from comment #0) > The problematic behavior seems to happen only with the macro, not from the > Print dialog or from the CLI --convert-to pdf call. Alternatively, you can select both sheet tabs with Shift + Click, and both pages will have content. In a way, it's consistent with the setting... Are macros supposed to ignore in-app active selection? Or should this be fixed by moving the active selection in the macro instead? I guess oSheet.createCursorByRange() is already doing that in the macro... Referenced Bugs: https://bugs.documentfoundation.org/show_bug.cgi?id=127592 [Bug 127592] [META] LibreOffice Basic incl."Option Compatible" modules -- You are receiving this mail because: You are the assignee for the bug.
