QPluginLoader Class Reference
[QtCore module]

Detailed Description

The QPluginLoader class loads a plugin at run-time.

QPluginLoader provides access to a Qt plugin. A Qt plugin is stored in a shared library (a DLL) and offers these benefits over shared libraries accessed using QLibrary:

• QPluginLoader checks that a plugin is linked against the same version of Qt as the application.
• QPluginLoader provides direct access to a root component object (instance()), instead of forcing you to resolve a C function manually.

An instance of a QPluginLoader object operates on a single shared library file, which we call a plugin. It provides access to the functionality in the plugin in a platform-independent way. To specify which plugin to load, either pass a file name in the constructor or set it with setFileName().

The most important functions are load() to dynamically load the plugin file, isLoaded() to check whether loading was successful, and instance() to access the root component in the plugin. The instance() function implicitly tries to load the plugin if it has not been loaded yet. Multiple instances of QPluginLoader can be used to access the same physical plugin.

Once loaded, plugins remain in memory until all instances of QPluginLoader has been unloaded, or until the application terminates. You can attempt to unload a plugin using unload(), but if other instances of QPluginLoader are using the same library, the call will fail, and unloading will only happen when every instance has called unload(). Right before the unloading happen, the root component will also be deleted.

In order to speed up loading and validation of plugins, some of the information that is collected during loading is cached in persistent memory (through QSettings). For instance, the result of a load operation (e.g. succeeded or failed) is stored in the cache, so that subsequent load operations don't try to load an invalid plugin. However, if the "last modified" timestamp of a plugin has changed, the plugin's cache entry is invalidated and the plugin is reloaded regardless of the values in the cache entry. The cache entry is then updated with the new result of the load operation.

This also means that the timestamp must be updated each time the plugin or any dependent resources (such as a shared library) is updated, since the dependent resources might influence the result of loading a plugin.

See How to Create Qt Plugins for more information about how to make your application extensible through plugins.

Note that the QPluginLoader cannot be used if your application is statically linked against Qt. In this case, you will also have to link to plugins statically. You can use QLibrary if you need to load dynamic libraries in a statically linked application.

Note: In Symbian the plugin stub files must be used whenever a path to plugin is needed. For the purposes of loading plugins, the stubs can be considered to have the same name as the actual plugin binary. In practice they have ".qtplugin" extension instead of ".dll", but this difference is handled transparently by QPluginLoader and QLibrary to avoid need for Symbian specific plugin handling in most Qt applications. Plugin stubs are needed because Symbian Platform Security denies all access to the directory where the actual plugin binaries are located.

See also QLibrary and Plug & Paint Example.

Property Documentation