This module implements a legacy binary UNO types format, still used by extensions and core code. Eventually the LibreOffice team want to migrate away from this format.
The module works on files and memory streams. Possibly the easiest way of understanding how the format works is to show an example of how to read and write a byte of data to a memory stream (writing to a file backed store works in almost the same way):
To open a file in memory, you do the following:
store::OStoreFile aFile;aFile.createInMemory()
To write to the file, you must first open a stream, then write to it. The following is an example of how to write a byte to the stream, and then read the byte back again.
ifaFile.isValid(); { store::OStoreStream aStream;if (aStream.create(aFile,"testnode", // normally the directory"testname", // normally the file name storeAccessMode::ReadWrite) { { std::unique_ptr<sal_uInt8[]>pWriteBuffer(newsal_uInt8[1]);pWriteBuffer[0] ='a'; sal_uInt32 writtenBytes;if (!(aStream.writeAt(0, // start offsetpWriteBuffer.get(),1, // number of bytes to write writtenBytes) // record the bytes written&& writtenBytes ==1)) {assert(false); } } { std::unique_ptr<sal_uInt8[]> pReadBuffer; sal_uInt32 readBytes;if (!(aStream.readAt(0, // start offsetpReadBuffer.get(),1, // number of bytes to read readBytes) // record the bytes read&& readBytes ==1)) {assert(false); } } } }
As the store is deprecated, I will not go into how it actually stores the files.
The registry holds the system's UNO type information in a database. The following data types are stored in the registry:
Modules
Structs
Enums
Interfaces
Exceptions
Services
Value types (aka constants)
Reading the registry
All keys in the registry are part of a module. To read the registry, you must first open it. To do this, you first instantiate a Registry object, and call open(). You then need to open the root key (the registry is a hierarchical key/value store), and from the root key you can find your subkey.
For example, say you have a registry file with a single module called ModuleA, containing a constant key "test", you would do the following:
UNOIDL (UNO Interface Definition Language) is a way of specifying types, services, and other entities used by UNO via a metalanguage of its own. UNOIDL should be seen as a specification language, and is the building block used by UNO to create UNO components, which consist of a variety of compiled libraries that interacts are are bound to the UNO infrastructure.
Starting in LibreOffice 7.5, developers will start to use the unoidl module to write and read UNO types. Changes made will mean that LibreOffice extensions are now incompatible with OpenOffice.org extensions, and any LibreOffice extensions developed before LibreOffice 4.1 will no longer work either. This has been a very necessary step in degunking extemely legacy code (the idlc module and regmerge utility are being removed).
The unoidl module actually handles more than just types, it also processes the UNO modules, services, singletons, etc. that make up actual object instances. These are managed via .idl (Interface Definition Language) files, and thus must be processed differently than the binary types.rdb file.
The first step in reading the registry is to load a provider, which does the hard work of actually reading from the binary types file. The provider is used to create the root cursor - this cursor holds the root location in the type registry. This is then used to navigate the registry.
Let's say you have a types.rdb file. To open the file for reading, you must first instantiate a provider manager, and have the manager produce the provider that does the work of parsing the rdb file: