Application Library Container
- Application Library Container
- Document Library Container
In an Apache OpenOffice installation the application library containers for Basic and dialogs are located in the directory <OfficePath>/share/basic or <OfficeUserPath>/user/basic. The library container index files are named script.xlc for the Basic and dialog.xlc for the Dialog library container. The "lc" in .xlc stands for library container.
The same directory contains the libraries created by the user. Initially only the library Standard exists for Basic and dialogs using the same directory. The structure of the library inside the directory is explained in the next section.
The user/basic directory is not the only place in the Apache OpenOffice installation where libraries are stored. Most of the autopilots integrated in Apache OpenOffice are realized in Basic, and the corresponding Basic and dialog libraries are installed in the directory <OfficePath>/share/basic. These libraries are listed in the library container index file as read-only links.
It is necessary to distinguish between libraries created by the user and the autopilot libraries. The autopilot libraries are installed in a directory that is shared between different users. In a network installation, the share directory is located somewhere on a server, so that the autopilot libraries cannot be owned directly by the user-specific library containers.
In the file system, a library is represented by a directory. The directory's name is the same as the library name. The directory contains all files that are necessary for the library.
Basic libraries can be protected with a password, so that the source code cannot be read by unauthorized persons. Dialog libraries cannot be protected with a password. This can be handled using the OpenOffice Basic Macro Organizer dialog that is explained in Managing Basic and Dialog Libraries. The password protection of a Basic library also affects the file format.
Libraries without Password Protection
Every library element is represented by an XML file named like the element in the directory representing the library. For Basic modules these files, following the specification in module.dtd, have the extension .xba. For dialogs these files, following the specification in dialog.dtd, have the extension .xdl. Additionally, the directory contains a library index file (library.dtd). These index files are named script.xlb for Basic and dialog.xlb for dialog libraries.
In the following example, an Application Basic library Standard containing two modules Module1 and Module2 is represented by the following directory:
<DIR> Standard | |--script.xlb |--Module1.xba |--Module2.xba
An application dialog library Standard containing two dialogs SmallDialog and BigDialog is represented by the following directory:
<DIR> Standard | |--dialog.xlb |--SmallDialog.xba |--BigDialog.xba
It is also possible that the same directory represents a Basic and a Dialog library. This is the standard case in the Apache OpenOffice, See the chapter Library organization in Apache OpenOffice. When the two example libraries above are stored in the same directory, the files from both libraries are together in the same directory:
<DIR> Standard | |--dialog.xlb |--script.xlb |--Module1.xba |--Module2.xba |--SmallDialog.xba |--BigDialog.xba
The two libraries do not affect each other, because all file names are different. This is also the case if a Basic module and a dialog are named equally, due the different file extensions.
Libraries with Password Protection
Only Basic libraries can be password protected. The password protection of a Basic library affects the file format, because binary data has to be stored. In plain XML format, the source code would be readable in the file even if it was not displayed in the Basic IDE. Also, the compiled Basic code has to be stored for each module together with the encrypted sources. This is necessary because, Basic could not access the source code and compile it as long as the password is unknown in contrast to libraries without password protection. Without storing the compiled code, Basic could only execute password-protected libraries once the user supplied the correct password. The whole purpose of the password feature is to distribute programs without giving away the password and source code, therefore this would not be feasible.
The following example shows a password-protected application Basic library Library1, containing three modules Module1, Module1 and Module3, is represented by the following directory:
<DIR> Library1 | |--script.xlb |--Module1.pba |--Module2.pba |--Module3.pba
The file script.xlb does not differ from the case without a password, except for the fact that the password protected status of the library is reflected by the corresponding flag.
Each module is represented by a .pba file. Like Apache OpenOffice documents, these files are package files ("pba" stands for package basic) and contain a sub structure that can be viewed with any zip tool. ).
A module package file has the following content:
<PACKAGE> Module1.pba | |--<DIR> Meta-Inf ' Content is not displayed here |--code.bin |--source.xml
The Meta-Inf directory is part of every package file and will not be explained in this document. The file code.bin contains the compiled Basic code and the file source.xml contains the Basic source code encrypted with the password.
| Content on this page is licensed under the Public Documentation License (PDL). |
