Re: [api-dev] Print Listeners in OOo 2.0.2 (Urgent!)
Have you seen the solution in my macro document? This might only work if the GUI is present (ie, not in headless mode). Tobias Krais wrote: Hi Hal, Code would be a big help so I could compare what we've got. I'll be glad to send you what I have. Right now I'm working with a wrapper class to handle basic functions. Do I understand, though, that you run the program once for each file you print? Or does it loop through and print multiple files without being re-run? My program runs once for each file. But modifying it shouldn't be a problem for it is in good object oriented style. It's not on this topic, but I see you had a question about getting the list of printers in BASIC. I can't do that, but I do have a routine that gets the lists of printers on a system from Java. It doesn't work directly with OOo, but it can get all the printers. Will that help you? Yes, it will. That will be the solution I plan to implement if it does not work in BASIC. I'll send you a private mail with the relevant code. Greetings, Tobias - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Andrew Pitonyak My Macro Document: http://www.pitonyak.org/AndrewMacro.odt My Book: http://www.hentzenwerke.com/catalog/oome.htm Info: http://www.pitonyak.org/oo.php See Also: http://documentation.openoffice.org/HOW_TO/index.html - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [api-dev] Print Listeners in OOo 2.0.2 (Urgent!)
Hello Tobias Hal I think I've been told, and likely here, that in 2.0.x, print listeners like this are no longer necessary, but I'm having a bit of a problem searching and finding this comment and what the background is. In 2.0.x, can I print, then close the document without listening for when the print job is done? Can someone confirm this for me? I've been stuck on this problem for about a month (I thought it was other possibilities, and had another couple issues as well) and I'm at a point where I need to solve it and my client is, understandably, anxious about it. Tried it without the print listener and it crashed. Guess it still needs listeners. I wrote a little Java program being able to do the same you want to do. It opens a document, prints it and closes it. Calling the program again prints the next document,... I also ran into troubles without the print listener. Closing the document too fast will crash the print job. A print job listener is good for other reasons, too. I can send you my code if needed. Its an easy thing. But well, its late in Europe and you wont get much help around this time... You do not need realy a print listener to know when printing of the document will be finished and you can close the document. The real problem you have ... printing is by default an asynchronous operation. And of course - if you try to dispose a document which is currently in printing state it can crash (at least it shouldnt ... but it can). The best solution: start the printing job with a well documented parameter Wait=true. see css.view.PrintOptions for further details. On the other side it can be important how do you close the document. Do you use dispose() or close(). Documentation say you have to preferr XClosable.close(). Further its always a good idea to control the lifetime of a document without any exception and call close(false). Means - please do not deliver the ownership to the document itself. It can work for a while ... but if you close the application it can make trouble. Because all documents not finished within her jobs ... but closed with false does not know how they should handle these situation right. They can of course handle it right ... but mostly they dont do it :-) Greetings, Tobias - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Regards Andreas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [api-dev] Print Listeners in OOo 2.0.2 (Urgent!)
On Tuesday 11 September 2007, Andreas Schlüns wrote: Hello Tobias Hal I think I've been told, and likely here, that in 2.0.x, print listeners like this are no longer necessary, but I'm having a bit of a problem searching and finding this comment and what the background is. In 2.0.x, can I print, then close the document without listening for when the print job is done? Can someone confirm this for me? I've been stuck on this problem for about a month (I thought it was other possibilities, and had another couple issues as well) and I'm at a point where I need to solve it and my client is, understandably, anxious about it. Tried it without the print listener and it crashed. Guess it still needs listeners. I wrote a little Java program being able to do the same you want to do. It opens a document, prints it and closes it. Calling the program again prints the next document,... I also ran into troubles without the print listener. Closing the document too fast will crash the print job. A print job listener is good for other reasons, too. I can send you my code if needed. Its an easy thing. But well, its late in Europe and you wont get much help around this time... You do not need realy a print listener to know when printing of the document will be finished and you can close the document. In my case, I print, then close, and that seems to be too fast. I tried without a print listener and it didn't work. The real problem you have ... printing is by default an asynchronous operation. And of course - if you try to dispose a document which is currently in printing state it can crash (at least it shouldnt ... but it can). The best solution: start the printing job with a well documented parameter Wait=true. see css.view.PrintOptions for further details. So I can set a print option of Wait to true and my program will wait until the document is printed? Do I understand that properly? That would simplify several questions I've had along the way. On the other side it can be important how do you close the document. Do you use dispose() or close(). Documentation say you have to preferr XClosable.close(). That's what I'm using. Further its always a good idea to control the lifetime of a document without any exception and call close(false). Means - please do not deliver the ownership to the document itself. It can work for a while ... but if you close the application it can make trouble. Because all documents not finished within her jobs ... but closed with false does not know how they should handle these situation right. They can of course handle it right ... but mostly they dont do it :-) But if I use Wait=true for printing, then close immediately after the doc has been printed, and only load in one at a time, then that should eliminate any problems, right? Hal - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [api-dev] Print Listeners in OOo 2.0.2 (Urgent!)
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hal Vaughan wrote:
On Tuesday 11 September 2007, Andreas Schlüns wrote:
Hello Tobias Hal
I think I've been told, and likely here, that in 2.0.x,
print listeners like this are no longer necessary, but I'm
having a bit of a problem searching and finding this
comment and what the background is.
In 2.0.x, can I print, then close the document without
listening for when the print job is done? Can someone
confirm this for me? I've been stuck on this problem for
about a month (I thought it was other possibilities, and
had another couple issues as well) and I'm at a point where
I need to solve it and my client is, understandably,
anxious about it.
Tried it without the print listener and it crashed. Guess it
still needs listeners.
I wrote a little Java program being able to do the same you
want to do. It opens a document, prints it and closes it.
Calling the program again prints the next document,...
I also ran into troubles without the print listener. Closing
the document too fast will crash the print job. A print job
listener is good for other reasons, too.
I can send you my code if needed. Its an easy thing. But well,
its late in Europe and you wont get much help around this
time...
You do not need realy a print listener to know when printing of
the document will be finished and you can close the document.
In my case, I print, then close, and that seems to be too fast. I
tried without a print listener and it didn't work.
The real problem you have ... printing is by default an
asynchronous operation. And of course - if you try to dispose a
document which is currently in printing state it can crash (at
least it shouldnt ... but it can).
The best solution: start the printing job with a well documented
parameter Wait=true. see css.view.PrintOptions for further
details.
So I can set a print option of Wait to true and my program will
wait until the document is printed? Do I understand that properly?
That would simplify several questions I've had along the way.
On the other side it can be important how do you close the
document. Do you use dispose() or close(). Documentation say you
have to preferr XClosable.close().
That's what I'm using.
Further its always a good idea to control the lifetime of a
document without any exception and call close(false). Means -
please do not deliver the ownership to the document itself. It
can work for a while ... but if you close the application it can
make trouble. Because all documents not finished within her jobs
... but closed with false does not know how they should handle
these situation right. They can of course handle it right ... but
mostly they dont do it :-)
But if I use Wait=true for printing, then close immediately after
the doc has been printed, and only load in one at a time, then that
should eliminate any problems, right?
Hal
-
To unsubscribe, e-mail: [EMAIL PROTECTED] For
additional commands, e-mail: [EMAIL PROTECTED]
Hi Hal,
this code is for you (I hope):
public class PrintDocument {
private static int flag;
public void fire() {
.
XPrintable xPrintable =
(XPrintable) UnoRuntime.queryInterface(XPrintable.class,
this.xComponent);
XPrintJobBroadcaster xPrintJobBroadcaster =
(XPrintJobBroadcaster) UnoRuntime.queryInterface(
XPrintJobBroadcaster.class, this.xComponent);
XPrintJobListener xPrintJobListener = new
Printeable();
xPrintJobBroadcaster.addPrintJobListener(xPrintJobListener);
xPrintable.print(this.getPrintOptions());
while (PrintDocument.flag ==
PrintableState.JOB_STARTED_value
|| PrintDocument.flag ==
PrintableState.JOB_SPOOLED_value) {
try {
Thread.sleep(100);
}
catch (InterruptedException e) {
System.err.println(e.getStackTrace());
}
}
.
}
private class Printeable implements XPrintJobListener {
public void printJobEvent(PrintJobEvent arg0) {
int state = arg0.State.getValue();
switch (state) {
case PrintableState.JOB_STARTED_value:
PrintDocument.flag = PrintableState.JOB_STARTED_value;
break;
case PrintableState.JOB_SPOOLED_value:
PrintDocument.flag = PrintableState.JOB_SPOOLED_value;
break;
case PrintableState.JOB_COMPLETED_value:
PrintDocument.flag =
PrintableState.JOB_COMPLETED_value;
Re: [api-dev] Print Listeners in OOo 2.0.2 (Urgent!)
Hello Hal, The real problem you have ... printing is by default an asynchronous operation. And of course - if you try to dispose a document which is currently in printing state it can crash (at least it shouldnt ... but it can). The best solution: start the printing job with a well documented parameter Wait=true. see css.view.PrintOptions for further details. So I can set a print option of Wait to true and my program will wait until the document is printed? Do I understand that properly? That would simplify several questions I've had along the way. It makes your XPrintable.print() call synchron ! If your call returns the document was printed (at least the content was transfered completely to the underlying print queue of your system). That means you can close the document afterwards without any problems and you can shutdown the whole office without any problems. On the other side it can be important how do you close the document. Do you use dispose() or close(). Documentation say you have to preferr XClosable.close(). That's what I'm using. OK. ... with close(true) I hope :-) Further its always a good idea to control the lifetime of a document without any exception and call close(false). Means - please do not deliver the ownership to the document itself. It can work for a while ... but if you close the application it can make trouble. Because all documents not finished within her jobs ... but closed with false does not know how they should handle these situation right. They can of course handle it right ... but mostly they dont do it :-) But if I use Wait=true for printing, then close immediately after the doc has been printed, and only load in one at a time, then that should eliminate any problems, right? Yes - and your code will be more readable and easy. There is no need to use polling code, sleeps, threads or listener. Only 3 lines of code are needed ... loadComponentFromURL() print() close() ... OK - excepting some further stuff to define all needed parameters :-) Hal - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Regards Andreas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [api-dev] Print Listeners in OOo 2.0.2 (Urgent!)
Hi Andreas,
So I can set a print option of Wait to true and my program will
wait until the document is printed? Do I understand that properly?
That would simplify several questions I've had along the way.
It makes your XPrintable.print() call synchron !
If your call returns the document was printed (at least the content
was transfered completely to the underlying print queue of your system).
That means you can close the document afterwards without any problems
and you can shutdown the whole office without any problems.
pretty cool your tip! Hal, I implemented it and tested it and I can
share the easy code with you:
-%-
// Querying for the interface XPrintable on the loaded document
XPrintable xPrintable = (XPrintable)
UnoRuntime.queryInterface(XPrintable.class, this.xComponent);
// Making the print job syncronous. Thus the program continues after
// printing is finished. A print job listener is not needed.
PropertyValue[] printOpts = new PropertyValue[1];
printOpts[1] = new PropertyValue();
printOpts[1].Name = Wait;
printOpts[1].Value = new Boolean(true);
try {
xPrintable.print(printOpts);
} catch (IllegalArgumentException e) {
e.printStackTrace();
}
-%-
Thanks Andreas for your tip!
Greetings, Tobias
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [api-dev] Print Listeners in OOo 2.0.2 (Urgent!)
On Tuesday 11 September 2007, Andreas Schlüns wrote: Hello Hal, The real problem you have ... printing is by default an asynchronous operation. And of course - if you try to dispose a document which is currently in printing state it can crash (at least it shouldnt ... but it can). The best solution: start the printing job with a well documented parameter Wait=true. see css.view.PrintOptions for further details. So I can set a print option of Wait to true and my program will wait until the document is printed? Do I understand that properly? That would simplify several questions I've had along the way. It makes your XPrintable.print() call synchron ! If your call returns the document was printed (at least the content was transfered completely to the underlying print queue of your system). That means you can close the document afterwards without any problems and you can shutdown the whole office without any problems. On the other side it can be important how do you close the document. Do you use dispose() or close(). Documentation say you have to preferr XClosable.close(). That's what I'm using. OK. ... with close(true) I hope :-) Further its always a good idea to control the lifetime of a document without any exception and call close(false). Means - please do not deliver the ownership to the document itself. It can work for a while ... but if you close the application it can make trouble. Because all documents not finished within her jobs ... but closed with false does not know how they should handle these situation right. They can of course handle it right ... but mostly they dont do it :-) But if I use Wait=true for printing, then close immediately after the doc has been printed, and only load in one at a time, then that should eliminate any problems, right? Yes - and your code will be more readable and easy. There is no need to use polling code, sleeps, threads or listener. Only 3 lines of code are needed ... loadComponentFromURL() print() close() ... OK - excepting some further stuff to define all needed parameters :-) I'm using this to define my print options: PropertyValue[] printOpts = new PropertyValue[2]; printOpts[0] = new PropertyValue(); printOpts[0].Name = Name; printOpts[0].Value = sPrinter; printOpts[1] = new PropertyValue(); printOpts[1].Name = Wait; printOpts[1].Value = true; Originally I set the array length to 1 and not 2 and the last 3 lines are new. If I break it down into two different PropertyValue[] objects, will setting the 2nd erase the first? When using it as above, I get an error: com.sun.star.lang.IllegalArgumentException: at com.sun.star.lib.uno.environments.remote.Job.remoteUnoRequestRaisedException(Job.java:275) at com.sun.star.lib.uno.environments.remote.Job.execute(Job.java:141) at com.sun.star.lib.uno.environments.remote.JobQueue.enter(JobQueue.java:377) at com.sun.star.lib.uno.environments.remote.JobQueue.enter(JobQueue.java:346) at com.sun.star.lib.uno.environments.remote.JavaThreadPool.enter(JavaThreadPool.java:106) at com.sun.star.lib.uno.bridges.java_remote.java_remote_bridge.sendRequest(java_remote_bridge.java:860) at com.sun.star.lib.uno.bridges.java_remote.java_remote_bridge.sendRequest(java_remote_bridge.java:809) at com.sun.star.lib.uno.bridges.java_remote.ProxyFactory$Handler.request(ProxyFactory.java:159) at com.sun.star.lib.uno.bridges.java_remote.ProxyFactory$Handler.invoke(ProxyFactory.java:141) at $Proxy4.print(Unknown Source) at com.thresh.agent.TNOOo.listenToPrint(TNOOo.java:409) at com.thresh.agent.TNOOo.docPrinter(TNOOo.java:329) at com.thresh.agent.TNOOo.access$3(TNOOo.java:285) at com.thresh.agent.TNOOo$2.run(TNOOo.java:481) at java.lang.Thread.run(Unknown Source) I can test it using two different objects for the property values, but since I'm using a computer with only one printer, I want to be sure I'm not overriding the printer name when I set the 2nd option. Hal - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [api-dev] Print Listeners in OOo 2.0.2 (Urgent!)
On Tuesday 11 September 2007, Tobias Krais wrote:
Hi Andreas,
So I can set a print option of Wait to true and my program
will wait until the document is printed? Do I understand that
properly? That would simplify several questions I've had along the
way.
It makes your XPrintable.print() call synchron !
If your call returns the document was printed (at least the content
was transfered completely to the underlying print queue of your
system). That means you can close the document afterwards without
any problems and you can shutdown the whole office without any
problems.
pretty cool your tip! Hal, I implemented it and tested it and I can
share the easy code with you:
-%-
// Querying for the interface XPrintable on the loaded document
XPrintable xPrintable = (XPrintable)
UnoRuntime.queryInterface(XPrintable.class, this.xComponent);
// Making the print job syncronous. Thus the program continues after
// printing is finished. A print job listener is not needed.
PropertyValue[] printOpts = new PropertyValue[1];
printOpts[1] = new PropertyValue();
printOpts[1].Name = Wait;
printOpts[1].Value = new Boolean(true);
try {
xPrintable.print(printOpts);
} catch (IllegalArgumentException e) {
e.printStackTrace();
}
-%-
Okay, I changed it from what I read here (specifying a boolean instead
of a string) to get this:
PropertyValue[] printOpts = new PropertyValue[2];
printOpts[0] = new PropertyValue();
printOpts[0].Name = Name;
printOpts[0].Value = sPrinter;
printOpts[1] = new PropertyValue();
printOpts[1].Name = Wait;
printOpts[1].Value = new Boolean(true);
I left the print listener in just in case there was a problem and that
caused a problem. I removed the print listener and it worked fine.
Much simpler code and I figure I might save a small amount of time on
each document since I can go on as soon as it finishes, instead of
possibly losing a bit of time sleeping in a loop. While that isn't
much time per document, in some cases my clients are printing hundreds
of documents and the time could add up. Not by much, but it might make
the pages print faster.
Hal
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [api-dev] Print Listeners in OOo 2.0.2 (Urgent!)
Hi Hal, I'm using this to define my print options: PropertyValue[] printOpts = new PropertyValue[2]; printOpts[0] = new PropertyValue(); printOpts[0].Name = Name; printOpts[0].Value = sPrinter; printOpts[1] = new PropertyValue(); printOpts[1].Name = Wait; printOpts[1].Value = true; Originally I set the array length to 1 and not 2 and the last 3 lines are new. If I break it down into two different PropertyValue[] objects, will setting the 2nd erase the first? No, for you are setting a different value. When using it as above, I get an error: com.sun.star.lang.IllegalArgumentException: So the argument is used in a wrong way: printOpts[1].Name = Wait; printOpts[1].Value = true; You set a string as the value, but a Boolean object is expected: printOpts[1].Name = Wait; printOpts[1].Value = new Boolean(true); Greetings, Tobias - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[api-dev] Print Listeners in OOo 2.0.2 (Urgent!)
Sorry to post an obnoxious Urgent comment in the header, but I'm online with a client's computer through VNC and if it's at all possible I need to resolve this problem while online. When I wrote my Java program that interfaces with OOo, I was using 1.0.x. All I'm doing is loading a file, printing it, closing it, then repeating with the next file. Originally, in 1.0.x, because I wanted to print, then close, then open a new file, then print again, I ran into problems when I closed a document that I had just tried to print. To solve that problem, I created a print listener. I would do everything necessary to get ready to print the document, including setting the print options and so on. Then I'd add a print listener, print, and would print, then have a loop that would sleep 1/100 of a second until the listener indicated the file was no longer printing. Then I return to the calling function which will then close the document and repeat the process by opening the next document. I think I've been told, and likely here, that in 2.0.x, print listeners like this are no longer necessary, but I'm having a bit of a problem searching and finding this comment and what the background is. In 2.0.x, can I print, then close the document without listening for when the print job is done? Can someone confirm this for me? I've been stuck on this problem for about a month (I thought it was other possibilities, and had another couple issues as well) and I'm at a point where I need to solve it and my client is, understandably, anxious about it. Any help, especially quickly, would be a HUGE help. I'm not trying to be arrogant about this, but I've done everything I can and I'm still boxed into a corner. Thanks for any insight into this! Hal - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [api-dev] Print Listeners in OOo 2.0.2 (Urgent!)
On Monday 10 September 2007, Hal Vaughan wrote: Sorry to post an obnoxious Urgent comment in the header, but I'm online with a client's computer through VNC and if it's at all possible I need to resolve this problem while online. When I wrote my Java program that interfaces with OOo, I was using 1.0.x. All I'm doing is loading a file, printing it, closing it, then repeating with the next file. Originally, in 1.0.x, because I wanted to print, then close, then open a new file, then print again, I ran into problems when I closed a document that I had just tried to print. To solve that problem, I created a print listener. I would do everything necessary to get ready to print the document, including setting the print options and so on. Then I'd add a print listener, print, and would print, then have a loop that would sleep 1/100 of a second until the listener indicated the file was no longer printing. Then I return to the calling function which will then close the document and repeat the process by opening the next document. I think I've been told, and likely here, that in 2.0.x, print listeners like this are no longer necessary, but I'm having a bit of a problem searching and finding this comment and what the background is. In 2.0.x, can I print, then close the document without listening for when the print job is done? Can someone confirm this for me? I've been stuck on this problem for about a month (I thought it was other possibilities, and had another couple issues as well) and I'm at a point where I need to solve it and my client is, understandably, anxious about it. Tried it without the print listener and it crashed. Guess it still needs listeners. Hal - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [api-dev] Print Listeners in OOo 2.0.2 (Urgent!)
Hi Hal, [...] I think I've been told, and likely here, that in 2.0.x, print listeners like this are no longer necessary, but I'm having a bit of a problem searching and finding this comment and what the background is. In 2.0.x, can I print, then close the document without listening for when the print job is done? Can someone confirm this for me? I've been stuck on this problem for about a month (I thought it was other possibilities, and had another couple issues as well) and I'm at a point where I need to solve it and my client is, understandably, anxious about it. Tried it without the print listener and it crashed. Guess it still needs listeners. I wrote a little Java program being able to do the same you want to do. It opens a document, prints it and closes it. Calling the program again prints the next document,... I also ran into troubles without the print listener. Closing the document too fast will crash the print job. A print job listener is good for other reasons, too. I can send you my code if needed. Its an easy thing. But well, its late in Europe and you wont get much help around this time... Greetings, Tobias - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [api-dev] Print Listeners in OOo 2.0.2 (Urgent!)
On Monday 10 September 2007, Hal Vaughan wrote: Sorry to post an obnoxious Urgent comment in the header, but I'm online with a client's computer through VNC and if it's at all possible I need to resolve this problem while online. ... I think I've been told, and likely here, that in 2.0.x, print listeners like this are no longer necessary, but I'm having a bit of a problem searching and finding this comment and what the background is. In 2.0.x, can I print, then close the document without listening for when the print job is done? Can someone confirm this for me? I've been stuck on this problem for about a month (I thought it was other possibilities, and had another couple issues as well) and I'm at a point where I need to solve it and my client is, understandably, anxious about it. I've found I *have* to have a print listener and watch for when the document is done printing. Here's more detail on what's happening (sorry for things being fragmented, but I'm under tremendous pressure to solve this). This is happening on a Windows XP system with 2 CPUs. I was using Java 6 but now I'm using Java 5 and that makes no difference. I have my own Windows XP system but I cannot duplicate the problem on my computer. This only happens when printing multiple files. Sometimes it happens after I print 2-3 files, sometimes it happens after 50 or more files. There's no pattern to how many files it has to print before there's a problem. When I get a problem, I get the OOo File Corrupt window saying there is a problem with a file and it will try to restore it the next time OOo starts. If I start OOo, I get an empty file in Writer, as always, but I don't get any file to restore. I suspect I'm getting an error with the null file after closing or something like that. I am NOT getting errors reported in Java from this. If I click on the Okay button on the error window, then my system keeps running but isn't able to load a file. At this point it's a bit confusing because I have to go through old code I haven't read in a year. What can make OOo, while being run from Java, report a bad file and NOT throw a Java error? Again, thanks for any insight on this! Hal - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [api-dev] Print Listeners in OOo 2.0.2 (Urgent!)
Hi Hal, Code would be a big help so I could compare what we've got. I'll be glad to send you what I have. Right now I'm working with a wrapper class to handle basic functions. Do I understand, though, that you run the program once for each file you print? Or does it loop through and print multiple files without being re-run? My program runs once for each file. But modifying it shouldn't be a problem for it is in good object oriented style. It's not on this topic, but I see you had a question about getting the list of printers in BASIC. I can't do that, but I do have a routine that gets the lists of printers on a system from Java. It doesn't work directly with OOo, but it can get all the printers. Will that help you? Yes, it will. That will be the solution I plan to implement if it does not work in BASIC. I'll send you a private mail with the relevant code. Greetings, Tobias - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [api-dev] Print Listeners in OOo 2.0.2 (Urgent!)
Hi Hal, I've found I *have* to have a print listener and watch for when the document is done printing. Here's more detail on what's happening (sorry for things being fragmented, but I'm under tremendous pressure to solve this). This is happening on a Windows XP system with 2 CPUs. I was using Java 6 but now I'm using Java 5 and that makes no difference. Yes. There shouldn't be a difference. I can use both, too. I have my own Windows XP system but I cannot duplicate the problem on my computer. Same OO version? Some printing issues relevant to me were solved up to OO 2.1. This only happens when printing multiple files. Sometimes it happens after I print 2-3 files, sometimes it happens after 50 or more files. There's no pattern to how many files it has to print before there's a problem. When I get a problem, I get the OOo File Corrupt window saying there is a problem with a file and it will try to restore it the next time OOo starts. If I start OOo, I get an empty file in Writer, as always, but I don't get any file to restore. I suspect I'm getting an error with the null file after closing or something like that. See the code I sent you. It first checks whether the file exists. Then opens it and prints it. It catches each error Java throughs and continues if needed. I am NOT getting errors reported in Java from this. If I click on the Okay button on the error window, then my system keeps running but isn't able to load a file. At this point it's a bit confusing because I have to go through old code I haven't read in a year. What can make OOo, while being run from Java, report a bad file and NOT throw a Java error? Again, thanks for any insight on this! I don't know right now. I'll send you an other private mail... Greetings, Tobias - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [api-dev] Print Listeners in OOo 2.0.2 (Urgent!)
On Monday 10 September 2007, Tobias Krais wrote: Hi Hal, I've found I *have* to have a print listener and watch for when the document is done printing. Here's more detail on what's happening (sorry for things being fragmented, but I'm under tremendous pressure to solve this). This is happening on a Windows XP system with 2 CPUs. I was using Java 6 but now I'm using Java 5 and that makes no difference. Yes. There shouldn't be a difference. I can use both, too. I have my own Windows XP system but I cannot duplicate the problem on my computer. Same OO version? Some printing issues relevant to me were solved up to OO 2.1. I use a custom install. It's not too customized, but ever since the Install group changed over from one installer to use RPMs on Linux and the Windows installer on Windows, it is a *major* pain to create a new install that is at all customized with OOo. I don't want to even touch the 2 day job it'll take me to adapt my current install to a new version. Even if there isn't much difference between 2.0.x to 2.1, it would still take me a number of hours to just go through the files and make sure it's all the same and prep the installs. (Are you listening, Install group? Documentation would be a major help here!) Also, after taking time to think, it seems this system did work properly for a while on this client's system, so I'm thinking it could be other issues. I've found the OOo API quite hard to learn, so it's just possible I made what I thought was a simple change and forgot about it. I'm reviewing my code and versions for changes now. I hope I did something dopey I can correct. This only happens when printing multiple files. Sometimes it happens after I print 2-3 files, sometimes it happens after 50 or more files. There's no pattern to how many files it has to print before there's a problem. When I get a problem, I get the OOo File Corrupt window saying there is a problem with a file and it will try to restore it the next time OOo starts. If I start OOo, I get an empty file in Writer, as always, but I don't get any file to restore. I suspect I'm getting an error with the null file after closing or something like that. See the code I sent you. It first checks whether the file exists. Then opens it and prints it. It catches each error Java throughs and continues if needed. I am NOT getting errors reported in Java from this. If I click on the Okay button on the error window, then my system keeps running but isn't able to load a file. At this point it's a bit confusing because I have to go through old code I haven't read in a year. What can make OOo, while being run from Java, report a bad file and NOT throw a Java error? Again, thanks for any insight on this! I don't know right now. I'll send you an other private mail... Got them -- looking at both emails now. Hal - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
