Loading a document on OpenOffice using an external Python program

Question

I'm trying to create a python program (using pyUNO ) to make some changes on a OpenOffice calc sheet.

I've launched previously OpenOffice on "accept" mode to be able to connect from an external program. Apparently, should be as easy as:

import uno
# get the uno component context from the PyUNO runtime
localContext = uno.getComponentContext()

# create the UnoUrlResolver
resolver = localContext.ServiceManager.createInstanceWithContext(
                            "com.sun.star.bridge.UnoUrlResolver", localContext)

# connect to the running office
ctx = resolver.resolve("uno:socket,host=localhost,port=2002;"
                       "urp;StarOffice.ComponentContext")
smgr = ctx.ServiceManager

# get the central desktop object
DESKTOP =smgr.createInstanceWithContext("com.sun.star.frame.Desktop", ctx)

#The calling it's not exactly this way, just to simplify the code
DESKTOP.loadComponentFromURL('file.ods') 

But I get an AttributeError when I try to access loadComponentFromURL. If I make a dir(DESKTOP), I've see only the following attributes/methods:

['ActiveFrame', 'DispatchRecorderSupplier', 'ImplementationId', 'ImplementationName',
'IsPlugged', 'PropertySetInfo', 'SupportedServiceNames', 'SuspendQuickstartVeto', 
'Title', 'Types', 'addEventListener', 'addPropertyChangeListener', 
'addVetoableChangeListener', 'dispose', 'disposing', 'getImplementationId', 
'getImplementationName', 'getPropertySetInfo', 'getPropertyValue', 
'getSupportedServiceNames', 'getTypes', 'handle', 'queryInterface', 
'removeEventListener', 'removePropertyChangeListener', 'removeVetoableChangeListener', 
'setPropertyValue', 'supportsService']

I've read that there are where a bug doing the same, but on OpenOffice 3.0 (I'm using OpenOffice 3.1 over Red Hat5.3). I've tried to use the workaround stated here, but they don't seems to be working.

Any ideas?

Answer 1

It has been a long time since I did anything with PyUNO, but looking at the code that worked last time I ran it back in '06, I did my load document like this:

def urlify(path):
     return uno.systemPathToFileUrl(os.path.realpath(path))

desktop.loadComponentFromURL(
        urlify(tempfilename), "_blank", 0, ())

Your example is a simplified version, and I'm not sure if you've removed the extra arguments intentionally or not intentionally.

If loadComponentFromURL isn't there, then the API has changed or there's something else wrong, I've read through your code and it looks like you're doing all the same things I have.

I don't believe that the dir() of the methods on the desktop object will be useful, as I think there's a __getattr__ method being used to proxy through the requests, and all the methods you've printed out are utility methods used for the stand-in object for the com.sun.star.frame.Desktop.

I think perhaps the failure could be that there's no method named loadComponentFromURL that has exactly 1 argument. Perhaps giving the 4 argument version will result in the method being found and used. This could simply be an impedance mismatch between Python and Java, where Java has call-signature method overloading.

Answer 2

This looks like issue 90701: http://www.openoffice.org/issues/show_bug.cgi?id=90701

See also http://piiis.blogspot.com/2008/10/pyuno-broken-in-ooo-30-with-system.html and http://udk.openoffice.org/python/python-bridge.html