OpenOffice.org peut être étendue, on peut lui ajouter des fonctionnalités en OooBasic, en C++, en Java en Python... Ces fonctionnalités ajoutées sont appelées add-on et l'on peut se demander comment OpenOffice.org peut connaître quelque chose sur ces codes. Ceci se fait à l'aide de la base de registre UNO à l'aide des outils regview, regcomp, regmerge et idlc.

1 Pourquoi une base de registre UNO ?
2 Comment utiliser la base de registres
3 Le démarrage (Bootstrap)
- 3.1 Démarrage UNO/C++ via defaultBootstrap_InitialComponentContext()
- 3.2 == Démarrage UNO/C++ via Bootstrap_InitialComponentContext()
4 Jouons un peu avec regview
5 Comment manipuler la base de registre en C++ ?

Pourquoi une base de registre UNO ?

Il est très commun pour un programmeur de réaliser un programme qui utilise une librairie statique. Si la librairie est dynamique, le problème de l'édition de lien est laissé au système d'exploitation. Ce système d'exploitation a à savoir si la librairie est déjà chargée en mémoire et dans le cas contraire où est le fichier correspondant. Mais que se passe-t-il si vous avez déjà un fichier binaire exécutable et que vous désiriez lui ajouter des fonctionnalités avec des librairies que vous créez ? Cela peut être réalisé avec Openoffice.org comme déjà mentionné. La première chose est qu'il est impossible pour votre binaire exécutable OpenOffice.org de connaître à l'avance le nom de la librairie que vous allez réaliser(c'est un nom que vous avez choisi).Il faut dons un mécanisme à OpenOffice.org pour retrouver ce nom et d'autres informations : ceci est le principal objectif de la base de registre UNO. Le nom des librairies n'est pas la seule information indispensable à gérer par cette base de registre. Si l'on imagine que l'on peut étendre avec plusieurs librairies, il faudra savoir que le sous-brogramme bidon1 vient de telle librairie et que bidon2 vient de telle autre. En OpenOffice.org l'élément central est l'interface et donc l'information pertinente est que telle interface se trouve dans telle librairie...

La base de registre UNO utilise des fichiers binaires d'extension rdb. Ce format binaire est difficile à lire par l'homme et un outil pour faciliter la lecture est donc fournit avec le SDK (aller au chapitre 10.3 pour voir une description de regview).

Template:Documentation/Tip

Template:Documentation/Note

Comment utiliser la base de registres

La documentation concernant la base de registre UNO existe et peut être consultée à l'adresse suivante : http://udk.openoffice.org/common/man/tutorial/uno_registries.html On peut aussi trouver de l'information à : http://www.ooomacros.org/dev.php sur

Add On Tool

Author: Bernard Marcelly

Add On Installer

Author: Didier Lachièze, with code from Danny Brewer, Bernard Marcelly and Andrew Brown

Basic Library Installer

Author: Danny Brewer, with code from Andrew Brown & Didier Lachièze

De mon point de vue la manière la plus simple d'ajouter de l'information dans la base de registres est de modifier le fichier unorc (sous linux) ou uno.ini (sous Windows). Vous devez mettre votre fichier your_library.uno.rdb dans le répertoire <OOo>/program, et éditer /modifier le fichier <OOo>/program/unorc (sous linux) en ajoutant ce que j'ai coloré en rouge ci-dessous :

#unorc or uno.ini
[Bootstrap] 
UNO_SHARED_PACKAGES=${$SYSBINDIR/bootstraprc:BaseInstallation}/share/uno_packages 
UNO_SHARED_PACKAGES_CACHE=$UNO_SHARED_PACKAGES/cache 
UNO_USER_PACKAGES=${$SYSBINDIR/bootstraprc:UserInstallation}/user/uno_packages 
UNO_USER_PACKAGES_CACHE=$UNO_USER_PACKAGES/cache 
UNO_TYPES=$SYSBINDIR/types.rdb ?$UNO_SHARED_PACKAGES_CACHE/types.rdb ?$UNO_USER_PACKAGES_CACHE/types.rdb 
UNO_SERVICES= ?$UNO_USER_PACKAGES_CACHE/services.rdb ?$UNO_SHARED_PACKAGES_CACHE/services.rdb $SYSBINDIR/services.rdb ?$SYSBINDIR/your_library.uno.rdb

Il ne faut pas oublier d'enregistrer la position de votre fichier your_library.uno.so dans le fichier your_library.uno.rdb. Cela est réalisé avec l'outil regcomp :

regcomp -Register -r your_library.uno.rdb -c <somewhere>/your_library.uno.so

Un autre moyen d'obtenir ce résultat est d'utiliser pkgchk ou unopkg depuis OOo2.X

Le démarrage (Bootstrap)

Bootstrapping peut être défini en disant que c'est un moyen d'obtenir le service manager. Nous présentons maintenant deux moyens de démarrage (bootstraping).

Démarrage UNO/C++ via defaultBootstrap_InitialComponentContext()

We have have already described this bootstrap method because it concerns the classical SDK example we started with in chapter 4 (see <OpenOffice.org1.1_SDK>/examples/DevelopersGuide/ProfUNO/CppBinding). We provide here two different views to explain how it works. First we recall with the Figure below how we program it. It's easy to see the first C++ instruction is

//C++
defaultBootstrap_InitialComponentContext();

But when drawing details from the figure we cannot infer how it works and particularly with registery. It's only because Figure below is a C++/Java programmer point of view.

To see what happens during the beginning of bootstrap, we go and see the binary in <OpenOffice.org1.1_SDK>/LINUXexample.out/bin where binaries are constructed by default makefiles. We see three files :

office_connect the binary executable
office_connectrc : file with this content :

UNO_TYPES=$SYSBINDIR/office_connect.rdb
UNO_SERVICES=$SYSBINDIR/office_connect.rdb

office_connect.rdb

The files construction will perhaps help us to understand beter. We give again the make dependency of office_connect in Figure 1.4 which shows us how office_connect.rdb is constructed :

a regmerge starting from types.rdb
a regcomp to register somes classics uno.so files.

And now to learn how office_connect.rdb is used we have to search in makefile how the binary is launched : the line

office_connect.run : $(OUT_COMP_BIN)/$(OUTBIN) $(OUT_COMP_BIN)/office_connectrc
	cd $(OUT_COMP_BIN) && $(OUTBIN)

is expanded as

cd ../../../../LINUXexample.out/bin && office_connect

which shows no reference to office_connect.rdb. Then we have to probe how it works.

the office_connectrc is automaticly loaded. One way to test that is to rename this file which gives as result

make: *** [office_connect.run] Erreur 134

renaming only office_connect.rdb gives the same error :

make: *** [office_connect.run] Erreur 134

renaming office_connect.rdb as office_connect2.rdb and changing office_connectrc content, as seen below, works well.

UNO_TYPES=$SYSBINDIR/office_connect2.rdb
UNO_SERVICES=$SYSBINDIR/office_connect2.rdb

Conclusion : we have found how it works : when you launch a binary it automaticaly load office_connectrc and put the file office_connect2.rdb in the good place.

== Démarrage UNO/C++ via Bootstrap_InitialComponentContext()

The documentLoader example (see <OpenOffice.org1.1_SDK>/examples/cpp/DocumentLoader) uses an other way to bootstrap. We want to describe it now. As usualy we first begin with program framework in the Figure below.

In this second case we clearly see that DocumentLoader.rdb file is involved and loaded. The only difference is with registry. We find again a rdb file but not a rc file. The consequence is the presence of a regcomp command specific to regitery the binary/executable file.

This example will not work if OpenOffice.org is not running. In this example, the interaction between OpenOffice.org and some.bin is through the network. In other words, the programs can run on different computers. You must run OpenOffice.org in such a way it waits for an UNO connection (here only from localhost) :

<Ooo>/program/soffice "-accept=socket,host=localhost,port=8100;urp;StarOffice.ServiceManager"

Jouons un peu avec regview

To do : put the example of chapter 7.3 in an other way C=omment voit-on la base de registre en OooBasic ?= OooBasic permet beaucoup de choses et en particulier une exploration de la base de registre. Le code de Danny Brewer présenté ici : http://www.oooforum.org/forum/viewtopic.php?t=8737 nous montre comment ? Examinons un peu plus en détail ce code :

'Listing 160 Code d'exploration de la base de registre en OOoBasic
REM  *****  BASIC  *****
Sub Main 
  oReflection = createUnoService( "com.sun.star.reflection.CoreReflection" ) 
  oInfo = oReflection.forName( "nom.dannybrewer.test.XDannysCalcFunctions1" ) 
  aMethods = oInfo.getMethods() 
  For i = 0 To UBound( aMethods ) 
    oMethod = aMethods( i ) 
    Print oMethod.getName() 
  Next 
End Sub

puis nous créons un fichier IDL :

Listing 161 Fichier IDL d'exemple
// IDL
#include <com/sun/star/uno/XInterface.idl>
#include <com/sun/star/lang/XInitialization.idl>
 
module my_module
{
 
interface XSomething : com::sun::star::uno::XInterface
{
	long getCount();
	void setCount( [in] long nCount );
	long increment();
	long decrement();
};
 
service MyService
{
    interface XSomething;
};
};

Avec ce fichier IDL il nous est possible de créer un fichier rdb et de l'enregistrer dans la base de registre. Maintenant OpenOffice.org fonctionne comme si nous avions une interface supplémentaire même si l'on n'a pas encore écrit le code correspondant. Evidemment, il nous est impossible d'utiliser ce service puis qu'il n'y a pas ded code corrrespondant, mais on peut le voir. Pour cela on modifie légèrement le code de Danny :

'Listing 162
REM  *****  BASIC  *****
'From Danny : http://www.oooforum.org/forum/viewtopic.php?t=8737 
Sub Main
  oReflection = createUnoService( "com.sun.star.reflection.CoreReflection" )
  oInfo = oReflection.forName( "my_module.XSomething" )
  aMethods = oInfo.getMethods()
  'XRay.XRay oInfo
  print  UBound( aMethods )+1 & " methods :  ****"
  For i = 0 To UBound( aMethods )
    oMethod = aMethods( i )
    Print oMethod.getName()
  Next
 
  aTypes = oInfo.getTypes()
  print  UBound( aTypes )+1 & " types :  ****"
  For i = 0 To UBound( aTypes )
    oType = aTypes( i )
    Print "Types : " + oType.getName()
  Next
 
  aInterfaces = oInfo.getInterfaces()
  print  UBound( aInterfaces )+1 & " interfaces :  ****"
  For i = 0 To UBound( aInterfaces )
    oInterface = aInterfaces( i )
    Print "Interfaces : " + oInterface.getName()
  Next
End Sub

qui lancé produit l'affichage suivant :

7 methods : ****
queryInterface acquire release getCount setCount increment decrement
3 types : ****
Types : com.sun.star.reflection.XIdlClass
Types : com.sun.star.lang.XTypeProvider
Types : com.sun.star.uno.XWeak
0 Interfaces : ****

où l'on peut voir parmi d'autres choses les quatre méthodes données dans le fichier IDL. Template:Documentation/Note

To do : continue...

Comment manipuler la base de registre en C++ ?

See the registery Class in the C++ documentation To do

FR/Documentation/Base de registres

Contents

Pourquoi une base de registre UNO ?

Comment utiliser la base de registres

Le démarrage (Bootstrap)

Démarrage UNO/C++ via defaultBootstrap_InitialComponentContext()

== Démarrage UNO/C++ via Bootstrap_InitialComponentContext()

Jouons un peu avec regview

Comment manipuler la base de registre en C++ ?

Views

Personal tools

Navigation

Search

Tools