Hal Vaughan wrote:
On Wednesday 08 August 2007, Juergen Schmidt wrote:
Hal Vaughan wrote:
I hope this is a simple and quick question. I have a program I
wrote in Java to work with OpenOffice.org back while it was in
version 1.0 and 1.1. At that point, doing anything with the API
was quite complex. All I have to do is:
- open a doc
- print that doc
- close the doc
- quite OOo when done with all the docs I'm printing
To create the interface in Java I had to create 3-4 objects and to
open a doc, I had to create several objects and printing required
that, too.
I need to make some changes and and am having some difficulties and
I'm heavily pressed for time. If the API is still basically the
same, I won't be looking over new materials, but I'd like to know
if it's changed so it's easier. For instance, I could create an
interface and send an Uno command for quit, but anything else I had
to do was much more complex.
Well the API is more or less the same. We've introduced some new
concepts which are not reflected by most API's at the moment
(compatibility and time reasons, which of course is sad enough).
Anyway if you use a socket connection you simplify the whole UNO
bootstrap stuff with one call (pipe connection to the new started or
connected to default office). If you interested in this, i would
recommend out NetBeans plugin and take a look to the UNO Client
Application project type that does some more packaging stuff for you
as well.
Thanks. Some of below matches what I have, but some looks easier.
You are under time pressure and i would suggest that you change
nothing at the moment. But for your records, the following should
work:
######
// the bootstrap API needs some special manifest entry and
// some glue code packaged with your jar
XComponentContext xContext = Bootstrap.bootstrap();
XComponentLoader xLoader =
(XComponentLoader)UnoRuntime.queryInterface(XComponentLoader.class,
xContext.getServiceManager().createInstanceWithContext(
"com.sun.star.frame.Desktop", xContext));
// load document hidden
PropertyValue[] args = new PropertyValue[1];
args[0] = new PropertyValue();
args[0].Name = "Hidden";
args[0].Value = new Boolean(true);
XComponent xDoc = (XComponent)UnoRuntime.queryInterface(
XTextDocument.class, xLoader.loadComponentFromURL(
sDocFileUrl, "_blank", 0, args));
That looks easier than what I was doing, so I may end up using it.
// set printer and print
XPrintable xPrintable = (XPrintable)UnoRuntime.queryInterface(
XPrintable.class, xDoc);
PropertyValue[] printerDesc = new PropertyValue[1];
printerDesc[0] = new PropertyValue();
printerDesc[0].Name = "Name";
printerDesc[0].Value = sPrinterName;
xPrintable.setPrinter(printerDesc);
// set print options if necessary
//PropertyValue[] printOpts = new PropertyValue[1];
//printOpts[0] = new PropertyValue();
//printOpts[0].Name = "Pages";
//printOpts[0].Value = "1";
xPrintable.print(null);
// maybe use a print listener to check your print jobs before
terminate
I found I had to use a print listener. If I didn't, then after
printing, if I tried to close a doc, I got errors.
mmh, you are probably right, in my simple test i used a small enough
document ;-)
// close document
XCloseable xCloseable = (XCloseable)UnoRuntime.queryInterface(
XCloseable.class, xDoc);
xCloseable.close(false);
Isn't there a problem with making sure it isn't modified when closing
it? I had problems with that and had to account for resetting that.
yes in the past, now printing a document doesn't change the document
when i remember correctly.
// terminate the office
XDesktop xDesktop = (XDesktop)UnoRuntime.queryInterface(
XDesktop.class, xLoader);
xDesktop.terminate();
#######
At this point I'm considering just using a kill command for this, since
I have to use it in other cases. I have one person I'm working with
who would run my program and it'd work fine, but she'd leave the
computer running for a while (on Windows XP) and after a few days,
she'd run it again, and it would freeze while connecting to OOo, so
I've had to put in a kill function to make sure if that happens, my
program doesn't lock up.
i don't like this concept and would prefer something based on ref counts
but anyway it's currently the only way to terminate the remote office
process and it's possible that other objects will raise an
TerminateVetoExecption and that it won't work (catch retry ...).
I know before, when I wrote what I have now, there was also an issue
that I couldn't access most functions without first having a document
loaded. If I recall, I couldn't quit OOo unless I first loaded in a
document (or made sure there was one loaded in).
sounds strange, true is that a lot of API's work only on or with
documents ... But terminate should be possible without loading a
document first.
Well you need some API calls but the advantage is that it is flexible
and you can use it from several languages.
With more multiple inheritance interfaces we would be able to reduce
the queryInterface calls and provide more intuitive views and access
to the underlying objects.
Thanks for the samples and information. I may use bits and pieces since
I am having to redo a few parts.
you are welcome and constructive feedback what we can improve is always
appreciated. Their is a lot of space for improvements but you should
always keep in mind that we don't have a specialized API for one
specific language where we can use all the language specific gimmicks.
We have already identified some things which should be avoided in new
API's and we will also try to improve existing API's.
Juergne
Hal
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
