Hi Ariel,
Thanks for the detailed reply and explaining to me the issues with my
problem.
I understand that I should take the following route to find a solution to my
problem:
The external application has to implement a sort of server, listening for
requests from your Basic macro.
In this respect, I found that the C++ remoteclient example of the SDK,
implements this behavior. Is this a good example for me to follow. My only
problem is that I start OpenOffice.org from my application through a DLL. The
DLL has all the api's which interact with OpenOffice. So I think, I can't start
my application as a server in a sense. However is it possible for me to specify
a named pipe as in the remoteClient example. The OOBasic code would then
communicate with my application using the named pipe.
The openOffice.org application will be launched using the string "
-accept=socket,host=localhost,port=2081;urp;Mypipe".
Then the external application will wait on the pipe "Mypipe", while the OOBasic
macro can access and write to the pipe "Mypipe".
Please let me know if this approach would work. Otherwise I will start working
on your suggested solution in the previous mail.
Many thanks,
Mangesh
-----Original Message-----
From: Ariel Constenla-Haile [mailto:[email protected]]
Sent: Friday, February 15, 2013 7:25 PM
To: [email protected]
Subject: Re: communicating with a connected external application using OOBasic
macro
Hi Mangesh Shukla,
On Fri, Feb 15, 2013 at 10:26:44AM +0000, Shukla, Mangesh wrote:
> Hi, I have an external application which connects to OpenOffice.org
> application using sockets. The connection string can be given as
> "uno:socket,host=localhost,port=2081 ". OpenOffice was started in
> accept mode with the above string. I have an application level macro
> which needs to call a function in the external application. I am
> hoping to use the bridge connection using sockets to make this
> communication work.
But you cannot use the same port, this port is reserved for OpenOffice, the
application is already listening on that port.
If I understood, what you are doing is:
- OpenOffice is started in listening mode, it accepts connections from
UNO bridges on port 2081
- you have an external application that interacts with OpenOffice; for
this, instead of using the simple bootstrap mechanism, you create
a UNO interprocess bridge using the connection URL
"uno:socket,host=localhost,port=2081"
- inside OpenOffice you have a Basic macro, and you want this Basic
macro to interact with the external application using a socket
Then, localhost:2081 is reserved for OpenOffice, listening in this port for UNO
interprocess connection. OpenOffice is an css.connection.XAcceptor, the UNO
bridge that uses your external application is a css.connection.XConnector.
If you want your Basic macro to communicate to the external application, the
external application has to be listening on another port, different from 2081,
and the Basic macro has to connect to it. You have:
OpenOffice listening in 2081, your application connects to OpenOffice in 2081,
your application listens in NNNN, your macro connects to NNNN. You can do all
this with the UNO API, or simplify it using your preferred language.
The external application has to implement a sort of server, listening for
requests from your Basic macro. I doubt that implementing this in UNO API would
be an easy task. If written in Python, the external application could use the
powerful SocketServer module; the macro can be in Basic, connecting using UNO
API; or make it simpler, write the macro in Python/Java and use Python/Java
directly to communicate to your external application.
Regards
--
Ariel Constenla-Haile
La Plata, Argentina
