Chargement d'un document sur OpenOffice en utilisant un programme Python externe

StackOverflow https://stackoverflow.com/questions/2153843

  •  23-09-2019
  •  | 
  •  

Question

Je suis en train de créer un programme de python (en utilisant pyuno) pour faire quelques changements sur une feuille OpenOffice calc.

Je l'ai déjà lancé OpenOffice en mode « accepter » pour pouvoir se connecter à partir d'un programme externe. Apparemment, devrait être aussi simple 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 déclaré , mais ils ne semble à travailler.

Toutes les idées?

Autres conseils

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 est pas là, l'API a changé ou il y a quelque chose d'autre mal, je l'ai lu dans votre code et il semble que vous faites tous les mêmes choses que j'ai.

Je ne crois pas que le dir () des méthodes sur l'objet de bureau sera utile, car je pense qu'il ya une méthode de __getattr__ utilisé pour proxy à travers les demandes et toutes les méthodes que vous avez affichaient sont l'utilité les méthodes utilisées pour l'objet de 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. donnant peut-être la version 4 argument se traduira par la méthode étant trouvé et utilisé. Cela pourrait être simplement une différence d'impédance entre Python et Java, où Java a la surcharge de méthode d'appel signature.

Licencié sous: CC-BY-SA avec attribution
Non affilié à StackOverflow
scroll top