Building ActiveX servers in Qt▲
The QAxServer module is part of the ActiveQt framework. It consists of three classes:
-
QAxFactory defines a factory for the creation of COM objects.
-
QAxBindable provides an interface between the Qt widget and the COM object.
-
QAxAggregated can be subclassed to implement additional COM interfaces.
Some example implementations of ActiveX controls and COM objects are provided.
Topics:
Using the Library▲
To turn a standard Qt application into a COM server using the QAxServer library you must add axserver to the QT variable in your .pro file.
An out-of-process executable server is generated from a .pro file like this:
TEMPLATE =
app
QT +=
axserver
RC_FILE =
qaxserver.rc
...
To build an in-process server, use a .pro file like this:
TEMPLATE =
lib
QT +=
axserver
CONFIG +=
dll
DEF_FILE =
qaxserver.def
RC_FILE =
qaxserver.rc
...
The files qaxserver.rc and qaxserver.def are part of the framework and can be used from their usual location (specify a path in the .pro file), or copied into the project directory. You can modify these files as long as it includes any file as the type library entry, ie. you can add version information or specify a different toolbox icon.
Using the axserver module will cause the qmake tool to add the required build steps to the build system:
-
Link the binary against qaxserver.lib instead of qtmain.lib
-
Call the idc tool to generate an IDL file for the COM server
-
Compile the IDL into a type library using the MIDL tool (part of the compiler installation)
-
Attach the resulting type library as a binary resource to the server binary (again using the idc tool)
-
Register the server. This step may require administrative privileges and can be skipped by setting the qaxserver_no_register configuration.
To skip the post-processing step, also set the qaxserver_no_postlink configuration.
Additionally you can specify a version number using the VERSION variable, e.g.
TEMPLATE =
lib
VERSION =
2.5
...
The version number specified will be used as the version of the type library and of the server when registering.
Out-of-Process vs. In-Process▲
Whether your COM server should run as a stand-alone executable or as a shared library in the client process depends mainly on the type of COM objects you want to provide in the server.
An executable server has the advantage of being able to run as a stand-alone application, but adds considerable overhead to the communication between the COM client and the COM object. If the control has a programming error only the server process running the control will crash, and the client application will probably continue to run. Not all COM clients support executable servers.
An in-process server is usually smaller and has faster startup time. The communication between client and server is done directly through virtual function calls and does not introduce the overhead required for remote procedure calls. However, if the server crashes the client application is likely to crash as well, and not every functionality is available for in-process s