Hi Drew,
Drew Jensen escribió:
Ariel Constenla-Haile wrote:
Hi Drew,
Drew Jensen escribió:
Designate specific printer for specific reports.
Definitely. Also specify what paper stock is to be used or which tray.
Good points - I fiddled a bit with printer settings using basic a
while back and had some issues time to look at that again.
there is no API for getting the available printers' names, nor the
tray, etc. See issues 87883 and 87495
http://www.openoffice.org/issues/show_bug.cgi?id=87883
http://www.openoffice.org/issues/show_bug.cgi?id=87495
IMHO, the one that developed the printing API was too lazy: internally
all these is available cf. the Printer class in /vcl/inc/vcl/print.hxx
For 87883
static const std::vector< rtl::OUString >& GetPrinterQueues();
For 87495
USHORT GetPaperBin() const;
BOOL SetPaper( Paper ePaper );
et al.
How many month can take to wrap this into a new or existing
interface/service?
I have no idea on that last question, but that was the problem 3 years
ago when I looked.
I could make this a Windows only feature, fairly easily.
But that solution is what left me cold before...all platforms is the goal.
So - Working plan:
Use the Java print services API in a function that could be called from
an OOBasic script?
All it really needs to do is return the names of installed print
services for the first cut. Then add support for paper bins, etc
afterwards. ( I don't know maybe that would be simple enough to include
in a first cut )
The jar file would be included with the report runner oxt file. ( or
maybe there is a broader audience for this? )
Well, that is my thinking at the moment and having just looked at the
documentation for JPS API it looks pretty straight forward.
Drew
IIRC you said you where thinking about moving the whole extension to
Java, sure you know the advantages of this, with the NetBeans IDE
plug-in everything is easier:
* easier and cleaner to debug, because when you debug the extension it
creates a new user directory inside the project's folder
* easier to re-package,: if you do any change, then you simple right
click and create the oxt (AFAIK with the BasicAddonBuilder you have to
do everything again)
* with the NetBeans IDE code is easier to maintain (it has refactoring,
local history, code completion, etc.), so there is no point of
comparison with the poor Basic IDE
* most important, you can use Java API to fill black holes in OOo API
If you don't want to move to Java, you can do as you said: wrap the Java
API in a UNO component and use it from OOo Basic ... but IMHO this will
duplicate your work: you will have to maintain the Java code and the
Basic code.
ps - the response on Issue 87495 was sure a lot of help..if the request
does not belong to the scripting subcomponent it would have been nice if
"ab" had changed the value to the appropriate one...I suppose I have
enough rights to do that instead as soon as I can figure out what the
appropriate subcomponent is.
mmm... I guess this is a gsl issue, or maybe a framework one... I'm not
very good at guessing what issue belongs to what component
Regards
Ariel.
--
Ariel Constenla-Haile
La Plata, Argentina
[EMAIL PROTECTED]
[EMAIL PROTECTED]
http://www.ArielConstenlaHaile.com.ar/ooo/
"Aus der Kriegsschule des Lebens
- Was mich nicht umbringt,
macht mich härter."
Nietzsche Götzendämmerung, Sprüche und Pfeile, 8.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
