Reassigned to HI.

HI->JSK: Please take a look, thanks.

I think this is not related to macros infact, there is a crash deeper inside 
the code, maybe the code which handels what is done when the print finishes. 
Maybe this code does not handle properly the situation that other subsystems 
are still printing.

To my imagination that can be the code which handles the dialog in which a 
print can be canceled while ooo prints. I guess it because in this scenario, 
the prints are done quite simulatneosly but I would guess that OOO GUI only 
handles one print-cancel-dialog at a time or at least the code was designed 
with the circumstances assumed that there is only one print command at a time.

maybe there is some documentation sothat i can tell the macro to not display 
that kind of cancel dialog?

I am unable to reproduce the problem. Can you try to ask your question on one of
the mailinglists? I'm quite certain there is a feasible solution for your issue.

Setting issue to "WorksForMe". Please note that you may reopen it at any time if
you feel this still is a bug.

Close

JSK, thanks for taking time to look into this. Since the problem still exists 
for me, what version of OOo and which OS did you use sothat it worked for you?

Hi Hakre,

I used Windows XP SP2 (de) and OOH680m16 (That's a OOo 2.4.1, latest and
greatest). Your sample macro was copied into the BASIC IDE and with a sample
document (Writer, just some text) i executed your macro. No crash.

I can not check against that version (i do not have it installed and I am not 
able to find a download of exact that version compiled for my system), it might 
be fixed in that version then.

That as well means for me that "CLOSED WORKSFORME" is wrong. The current status 
should reflect that it works for others in an unstable version only. I could 
wait for the 2.4.1 release to try it again then. So I reopen the Issue with 
COMMENT: Might be solved in 2.4.1

Might be solved in 2.4.1 as reported by jsk.

I finally was able to update to OOo 2.4.1 and check against it. In comparison 
to Version 2.4.0 this time OOo Document Recovery pops up (OpenOffice.org 
Dokumentenwiederherstellung). When running Document Recovery, OOo Crashes again.

So I can only confirm that exact Error again, this time with Version 2.4.1.

How To reproduce:

* Takeover the Code in the first comment
* Adopt the script to two existing printer names in your configuration
* Create a new toolbar
* Add a button to the new toolbar that represent the Macro "PrintJob"
* Save the new Toolbar
* Press the Button
* OOo Crashes

Now i got it. Confirmed.

Program received signal SIGSEGV, Segmentation fault.
0x00922215 in String::Erase ()
   from /opt/staroffice9/program/../basis-link/program/libtlli.so
(gdb) where
#0  0x00922215 in String::Erase ()
   from /opt/staroffice9/program/../basis-link/program/libtlli.so
#1  0x012086fe in ?? ()
   from /opt/staroffice9/program/../basis-link/program/libvclli.so
#2  0x011b86ed in ?? ()
   from /opt/staroffice9/program/../basis-link/program/libvclli.so
#3  0x011b88c8 in ?? ()
   from /opt/staroffice9/program/../basis-link/program/libvclli.so
#4  0x011645db in Timer::Timeout ()
   from /opt/staroffice9/program/../basis-link/program/libvclli.so
#5  0x01164207 in Timer::ImplTimerCallbackProc ()
   from /opt/staroffice9/program/../basis-link/program/libvclli.so
#6  0x01fb92bb in X11SalData::Timeout ()
   from /opt/openoffice.org/basis3.0/program/libvclplug_genli.so
#7  0x05f8e70b in ?? ()
   from /opt/openoffice.org/basis3.0/program/libvclplug_gtkli.so
#8  0xb7f6f558 in ?? ()
#9  0x0141bf80 in ?? ()
   from /opt/staroffice9/program/../basis-link/program/libvclli.so
#10 0x01f6f264 in ?? () from /lib/libglib-2.0.so.0
#11 0xbfccbbac in ?? ()
#12 0x085b98d8 in ?? ()
#13 0xbfccbb38 in ?? ()
---Type <return> to continue, or q <return> to quit---
#14 0x05f8e731 in ?? ()
   from /opt/openoffice.org/basis3.0/program/libvclplug_gtkli.so
#15 0xb7f90908 in ?? ()
#16 0xbfccbb68 in ?? ()
#17 0x01ec67c6 in ?? () from /lib/libglib-2.0.so.0
Backtrace stopped: previous frame inner to this frame (corrupt stack?)

Reproduction succeeded for both 2.4.1, 3.0 (m19) on Windows and Linux.

@pl: please take over

pl->cd: The crash occurs because of the first printer being destroyed while a
print job is active; this is not allowed. The printer is destroyed by SwView
which tries to set a new printer. I talked to os and he told me that two print
jobs at the same time should not be possible; he thinks this should be prevented
in framework.

for a generel maturity and in-depth stability I would like to see at least an 
exception here that can be catched.

on the scripting-level it would be great to have a kind of wait-until-finished 
command/flag or a stillPrinting Property or similar to circumvent the bug on 
the scripting side. Maybe like in this pseudo code:

dim args1(1) as new com.sun.star.beans.PropertyValue
args1(0).Name = "Printer"
args1(0).Value = printer
args1(1).Name = "UIWait"
args1(1).Value = true
dispatcher.executeDispatch(document, ".uno:Printer", "", 0, args1())
dispatcher.waitForExecuteDispatchDone(document, ".uno:Printer")

I'm quite new to scripting OOo and I do not know, maybe there is a parameter to 
wait but I had problems to find those dispatching commands well documented even 
tough I'm quite tekky.

code freeze missed, target adjusted

Just some Feedback: Tested against OOo 3.0.0 OOO300m9 (Build:9358). Does still 
crash (should though I think if the freeze was missed).

The right approach seems to be:

return Error in virtual method SfxViewShell::SetPrinter(), as this is the
"offending" code part. Not only a second print job, but every attempt to set a
new printer while the old one is printing, will leads to a crash.
In case of printing the error will be handled in SfxViewShell::DoPrint.

Interesting observation: via API this crash can't happen as setPrinter() waits
until printing on the current printer has finished. I prefer to let the call fail.

@akre: a "Wait" property exists already, so your suggested workaround can be
used. Unfortunately (and for historical reasons - as always ;-)) the parameters
differ for the dispatching and the "real" API:

Dispatching:

dim args1(1) as new com.sun.star.beans.PropertyValue
args1(0).Name = "PrinterName"
args1(0).Value = printer
args1(1).Name = "Asynchron"
args1(1).Value = false
dispatcher.executeDispatch(document, ".uno:Print", "", 0, args1())

Using XPrintable at the document:

dim args1(0) as new com.sun.star.beans.PropertyValue
args1(0).Name = "Name"
args1(0).Value = printer
doc.setPrinter( args1() )

dim args2(0) as new com.sun.star.beans.PropertyValue
args2(0).Name = "Wait"
args2(0).Value = true
doc.print( args2() )

Fixed in sfx2, sw, sc, sd, starmath.
Attempt to change printer or printer settings while a document is printing now
will be rejected.

Thanks for looking into the Issue and fixing it at its root.

I just tested the workaround provide by mba and it works perfectly. Thanks for 
that, mba! You just made me smile. 

I've made an interesting observation when I tried to re-queue a rejected
printing dispatch and I found out that the second call never arrived in my code. 

If two printing calls are dispatched the second call will be rejected already by
the dispatching implementation. The problem in the macro is that the Printer is
set in an own dispatch (instead of passing the printer name to the dispatch
call) and for the "uno:Printer" call the "busy" check is not executed.

So it seems that the fix we need is to guard a busy printer against that command
also and this should work with my fix.

Unfortunately this way a queuing is not possible, so the result of my fix will
be that the second print job is not done. So using the "Wait" parameter seems to
more than a workaround, it's the only way to get both jobs done.

Duh, I was blind.

Of course it is easy to queue API requests, just remove the code that disables
printing commands in case of pending print jobs. Works fine and smooth now, with
my fix there is no reason to use the "Wait" property anymore. :-)

@jsk: please verify

2 pages, no crash. Verified.

Close