Hi, On Mon, Feb 18, 2013 at 08:24:34AM +0000, Shukla, Mangesh wrote: > 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.
How did you interpret that example? This example is explained here: http://wiki.openoffice.org/wiki/Documentation/DevGuide/WritingUNO/Server_Use_Case The UNO executable is launched as a server, listening on localhost:2002 and exporting a *single* UNO object, the one implementing the service com.sun.star.io.Pipe This means, the client connects to localhost:2002 and all it will get is the com.sun.star.io.Pipe implementation, no way to bootstrap a full office with all its services. I guess this is not what you want. Besides, the UNO executable launched as a server listens for connections with the urp protocol: - there is no way for your Basic macro to connect to localhost:2002 and write arbitrary stuff in the connection, as the connection only understands the URP protocol - there is no way for you to read what is written in that connection, on the server side, you don't have access to the underlying internal acceptor implementation. I guess you got confused by that example, because the client is writing and reading in a pipe, but that pipe is the UNO component that is exported by the server; in the server, only the C++ implementation of the component has access to the underlying pipe. But note that this pipe is not the pipe used by the server's acceptor (in fact, in the example, the server is launched listening on a socket, so the server acceptor has a socket, not a pipe). In short, when you launch the UNO executable as a server, listening on a resource (socket or pipe) and then launch another process of the UNO executable as a client that connects to that server, the interprocess connection is using the URP protocol, you (whether you have a component in the server or in the client) will never be able to write/read on that connection, your code does not own it, it's a connection between the server and the client bridge. > 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. But not using the UNO executable. The UNO executable, in the server user case, exports an arbitrary UNO component, and that's all. > However is it possible for me to specify a named pipe as in > the remoteClient example. Please look at the example, there is no named pipe at all. All interprocess communication is done via socket: uno:socket,host=localhost,port=2083;urp;MyPipe the MyPipe there is not the name of a named pipe, it's simple the name of the remote object; the remote object is the UNO component that export the server, and is specified in the command line when you launch it: uno -s com.sun.star.io.Pipe MyPipe is not a named pipe, it a UNO component. Change the command line by uno -s com.sun.star.io.TextInputStream And name the remote object MyTextInputStream, you'll understand better the example. > 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". As explained above, "Mypipe" is not a named pipe, it's an alias for the uno component exported by the server. Regards -- Ariel Constenla-Haile La Plata, Argentina
pgpFA5P2yqW_K.pgp
Description: PGP signature
