 | Start a set with this search |
 | Include this search in one of my sets |
 | Exclude this search from one of my sets |
 | Permalink to these results Paste this link in email or IM: |
 | Atom feed for tracking future search results Paste this URL into your reader: |
2 messages in org.openoffice.fr.progRe: [prog] généralités Avis sur Docs ...| From | Sent On | Attachments |
|---|---|---|
| Philippe progOO | Jan 20, 2005 1:24 am | |
| Bernard Marcelly | Jan 20, 2005 5:35 am |
| Permalink for this message Paste this link in email or IM: |
| Permalink for this thread Paste this link in email or IM: |
| Atom feed for this thread Paste this URL into your reader: |
| Subject: | Re: [prog] généralités Avis sur Docs OO, SDK et formalisme | Actions... |
|---|---|---|
| From: | Bernard Marcelly (marc...@club-internet.fr) | |
| Date: | Jan 20, 2005 5:35:46 am | |
| List: | org.openoffice.fr.prog | |
Le 2005-01-20 10:24, Philippe progOO a écrit :
Mais j'éprouve quelques diffcultés à utiliser la documentation du SDK où je chercherais volontiers les instructions disponibles par type. (...) etc... Existe t-il une telle documentation où la description des propriétés, méthodes suivrait une arborescence et dont les entrées seraient du genre : je cherche ce qui pilote une cellule. Autrement dit comment arriver à savoir quel service il faut utiliser au bon moment ? (exemple du t_dummy ci-dessus)
L'API OpenOffice.org décrit des objets UNO, et non des instructions. En gros, il est composé de services; chaque service comporte en général des propriétés et des méthodes; celles-ci n'ont de validité que pour un objet supportant le service. Une méthode peut renvoyer une valeur ou un objet supportant un ou plusieurs services. La description idl de l'API suit une arborescence, où on peut par exemple trouver les propriétés et méthodes pour une cellule. Le problème est qu'on se perd dans la jungle, comme dit Agnès. Pour comprendre, il faut lire le Developer's Guide - en fait il faut le relire pas mal de fois - mais ce document n'est pas fait pour un programmeur utilisateur mais plutôt pour un développeur d'OpenOffice.org ou d'une variante. Et le Developer's Guide n'explique pas tout l'API. C'est pour cela que divers auteurs ont écrit des documents comme ceux cité, après avoir passé pas mal de temps. On peut lire aussi le HowTo l'API (presque) sans peine ou le livre Programmation OpenOffice.org qui est plus complet (mais pas exhaustif vu l'ampleur de l'API).
comment arriver à trouver si getDate() existe dans un champ date ?
Le moyen le plus rapide est d'utiliser Xray sur cet objet, et d'accéder à la doc API de la méthode trouvée pour vérifier sa signification. Mais tout n'est pas documenté...
comment trouver la liste et la signification d'instruction telle que
FramePosSize =
ThisComponent.getCurrentController().Frame.getComponentWindow.PosSize
Cette instruction (extraite d'une version obsolète de Xray) est typique de l'utilisation des objets fournis par l'API : ThisComponent est une fonction API propre à Basic qui renvoie un objet possédant la méthode getCurrentController qui renvoie un objet possédant la méthode getFrame (ici Basic présente une pseudo-propriété Frame) qui renvoie un objet possédant la méthode getComponentWindow qui renvoie un objet comportant une méthode getPosSize qui renvoie un objet, finalement affecté à FramePosSize. On aurait pu écrire ceci en plusieurs lignes, avec des variables intermédiaires.
Au niveau de la syntaxe dans le Basic (...)
Chacun a ses conventions, et la tienne est classique et raisonnable. Personnellement je recommande d'utiliser Option Explicit en tête de chaque module et de déclarer (par Dim) toutes les variables utilisées en précisant leur type. On détecte ainsi nombre d'erreurs de frappe et on facilite la relecture.
Bonne journée Bernard