Chargement d'un document sur OpenOffice à l'aide d'un programme Python externe

Question

J'essaie de créer un programme python (en utilisant pyUNO) pour apporter des modifications à une feuille de calcul OpenOffice.

J'ai déjà lancé OpenOffice en mode "Accepter" pour pouvoir me connecter à partir d'un programme externe. Apparemment, devrait être aussi facile que:

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') 

mais je reçois un AttributeError lorsque je tente d'accéder loadComponentFromURL. Si je fais un dir(DESKTOP), je l'ai vu que les attributs/méthodes suivantes:

['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'] 

J'ai lu qu'il ya un bug où faire la même chose, mais sur OpenOffice 3.0 (j'utilise OpenOffice 3.1 sur Red Hat5.3). J'ai essayé d'utiliser la solution de contournement énoncée here, mais ils ne semblent pas fonctionner.

Des idées?

Answer 1

Cela ressemble question 90701: http://www.openoffice.org/issues/show_bug.cgi?id=90701

Voir aussi http://piiis.blogspot.com/2008/10/pyuno-broken-in-ooo-30-with-system.html et http://udk.openoffice.org/python/python-bridge.html

Answer 2

Il a été longtemps que je l'ai fait quoi que ce soit avec pyuno, mais en regardant le code qui a travaillé la dernière fois je l'ai couru de retour en '06, je l'ai fait mon document de charge comme ceci:

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

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

Votre exemple est une version simplifiée, et je ne suis pas sûr si vous avez supprimé les arguments supplémentaires intentionnellement ou non intentionnellement. Si loadComponentFromURL n'est pas là, alors l'API a changé ou il y a quelque chose d'autre qui ne va pas, j'ai lu votre code et on dirait que vous faites exactement les mêmes choses que moi.

Je ne crois pas que la dir() des méthodes sur l'objet de bureau sera utile, car je pense qu'il ya une méthode __getattr__ utilisé pour proxy à travers les demandes et toutes les méthodes que vous avez affichaient sont méthodes utilitaires utilisées pour l'objet stand-in pour le com.sun.star.frame.Desktop.

Je pense que peut-être l'échec pourrait être qu'il n'y a pas de méthode nommée loadComponentFromURL qui a exactement 1 argument. Peut-être qu'en donnant la version à 4 arguments, la méthode sera trouvée et utilisée. Cela pourrait simplement être une inadéquation d'impédance entre Python et Java, où Java a surchargé la méthode de signature d'appel.