Hola Andrés,
disculpas por responder tarde, estoy muy ocupado trabajando en la
implementación de
http://wiki.services.openoffice.org/wiki/User:Arielch/Menu_API_Enhancement
que será incluido en OOo 3.1
Andrés González escribió:
Hola compañeros de la lista, hoy me he suscrito y estoy mas perdido que un
pulpo en un garaje, pero bueno como primera prueba mis siguiente pregunta:
Programo en fivewin + xharbour, actualmente estoy realizando automatización
con openoffice wirter. Quisiera si alguno sabe como se hace en cualquier
lenguaje preferiblemente de la rama de xbase,
antes de saber cómo se hace, habría que saber si es posible emplear la
API de OOo desde el lenguaje que deseas, y qué tipo de "automatización"
deseas.
Básicamente puedes automatizar OOo mediante:
* una aplicación cliente
* un componente empleando la tecnología UNO
* scripting
Componentes es posible desarrollar en C++, Java, Python.
Para scripting puedes emplear el lenguaje nativo de OOo (OOo Basic),
JavaScript, BeanShell, e incluso Python y Java (prueba los ejemplos en
el menú "Herramientas" - "Macros" - "Ejecutar macro").
Además, OOo posee un Automation Bridge que soporta la tecnología de
Microsoft conocida genéricamente bajo el nombre Automation (COM, OLE).
Esto implica que puedes programar desde cualquier lenguaje que soporte
MS Automation, como Visual Basic, C++, JScript, VB Script. (v.
http://wiki.services.openoffice.org/wiki/Documentation/DevGuide/ProUNO/Bridge/Automation_Bridge
http://udk.openoffice.org/common/man/spec/ole_bridge.html)
También hay un CLI Language Binding que permite programar desde C# y
VB.NET (v.
http://wiki.services.openoffice.org/wiki/Documentation/DevGuide/ProUNO/CLI/CLI_Language_Binding)
Como xHarbour tiene soporte OLE, puedes emplear el Automation Bridge de
OOo, lee la bibliografía citada arriba sobre cómo funciona el bridge.
Información más específica tal vez encuentres googleando "xharbour
openoffice"[1].
Lamentablemente, podrás implementar interfaces pero no desarrollar
componentes UNO. Chino?
Si estás familiarizado con el mecanismo de Listeners (en lenguajes como
Java) o signals o slots (en implementaciones de GUI toolkits), un
ejemplo de "implementar interfaces" en OOo son las interfaces Listeners:
te registras en un objeto para recibir determinada información frente a
determinados eventos (por ejemplo: un com.sun.star.awt.XMenuListener se
registra en un com.sun.star.awt.XMenu para recibir información cuando un
ítem del menú es seleccionado, activado, etc. Para eso debes implementar
XMenuListener - cosa que es posible desde OLE)
Pero la forma más fácil de agregar un item en un menú, o crear tu propio
menú, es mediante una extensión (son como los add-ons de
Firefox/Thunderbird). Esto se lleva a cabo mediante un simple archivo
XML de configuración. A cada ítem que agregas debes asignar un comando,
y OOo lo invocará cuando el usuario lo seleccione. Esto puedes
realizarlo desde un lenguaje de scripting como OOo Basic, o
implementando un componente en Java/C++/Python; pero *no* desde OLE.
Desde OLE sólo puedes crear una aplicación cliente, que instancia el
ServiceManager (una especie de central de OOo a la cual le pides que
instancie los objetos que deseas), esta aplicación es "cliente" porque
trabaja "desde afuera" de OOo (no como una extensión que es integrada en
OOo).
Esto tiene varias desventajas (por ejemplo, no es fácil de distribuir
como una extensión [¿estas pensando en algo para distribuir, o sólo para
tu propio uso?]).
Principalmente, la forma de agregar un menú es muchísimo más complicada
(pero posible: las imágenes que ves en
http://wiki.services.openoffice.org/wiki/User:Arielch/Menu_API_Enhancement
son algunas producto de una aplicación cliente que se conecta remotte. a
OOo y agrega un menú).
La razón es que, mientras que con una extensión es OOo quien cuida del
menú agregado, con una aplicación cliente es tu responsabilidad, y el
menú es destruido y reconstruido bajo ciertas circunstancias, por ende
el ítem que tú agregas es "transient" [lit. "transitorio", pero mejor
"efímero"]; y tú debes registrarte para recibir información sobre dichos
cambios, y reconstruir tu menú cada vez que el menú ppal. es destruido y
reconstruido.
También existe la posibilidad de emplear la API que permite configurar
la UI [v. interfaces en
http://api.openoffice.org/docs/common/ref/com/sun/star/ui/module-ix.html],
pero esto agrega elementos permanentte. (o hasta que el usuario decida
eliminarlos).
Con respecto a botones en barras de herramienta, esto es posible
mediante una extensión, o mediante la API de config. de la UI; imposible
de forma "transient" pues no existe[2] API para acceder a una barra y
manipularla, como sí puedes hacerlo con un menú.
En conclusión, dependiendo de lo que desees hacer (algo para tí o para
distribuir; algo multi-plataforma o sólo para Win; etc. ...), y el
trabajo que estés dispuesto a invertir, tal vez debas pensar en otro
lenguaje de programación para implementarlo.
Si una aplicación cliente satisface tus necesidades, el soporte OLE
puede ser suficiente.
Saludos
Ariel.
[1] como http://www.nabble.com/developing-with-Windows-td16333683.html
http://objectmix.com/xharbour/192376-openoffice-automation.html
[2] Para OOo 3.x sí estará disponible la API que estoy desarrollando,
que permitirá manipular barras de herramienta (Toolbox/Toolbar) y de
estado (StatusBar)... pero "3.x" significa "no este año" :-(
--
Ariel Constenla-Haile
La Plata, Argentina
[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]
