Walkthrough: Using Qt objects in Microsoft .NET
IntroductionIn the following walkthrough we will show how Qt objects can be used in a .NET environment, and how .NET objects can be used in a Qt environment.
Qt vs .NETQt is a C++ library and is compiled into traditional, native binaries that make full use of the performance provided by the runtime environment. One of the key concepts of .NET is the idea of "intermediate language code" - the source code is compiled into a bytecode format, and at runtime, that bytecode is executed in a virtual machine - the Common Language Runtime (CLR). Another key concept is that of managed code. This is essentially intermediate language code written in such a way that the CLR can take care of the memory management, i.e. the CLR will do automatic garbage collection, so the application code does not need to explicitly free the memory for unused objects. The MS compilers for C# and VB.NET will only produce managed
code. Such programs cannot directly call normal, native functions
or classes. (1) The MS C++ compiler for .NET on the other hand, can produce both
normal and managed code. To write a C++ class that can be compiled
into managed code, the developer must flag the class as managed using
the __gc keyword, and restrict the code to only use the subset of
C++ known as "Managed Extensions for C++", or MC++ for short. The
advantage is that MC++ code can freely call and use normal C++
functions and classes. And it also works the other way around: normal
C++ code can call managed functions and use managed classes (e.g. the
entire .NET framework class library), including managed functions and
classes implemented in C# or VB.NET. This feature of mixing managed
and normal C++ code immensely eases the interoperability with .NET,
and is by Microsoft referred to as the "It Just Works" (IJW) feature.
This document demonstrates two different ways of integrating normal
C++ code (that uses Qt) with managed .NET code. First, the manual way
is presented, which includes using a thin MC++ wrapper class around
the normal Qt/C++ class. Then, the automated way is presented, which
utilizes the ActiveQt framework as a generic bridge. The advantage of
the first method is that it gives the application developer full
control, while the second method requires less coding and relieves the
developer of dealing with the conversion between managed and normal
data objects.
The impatient reader, who right away wants to see a QPushButton and a
custom Qt widget (QAxWidget2) run in a .NET GUI application is referred to the example
directory of ActiveQt. It contains the result of this walkthrough
using both C# and VB.NET, created with Visual Studio.NET (not 2003).
Load examples/dotnet/walkthrough/csharp.csproj,
examples/dotnet/walkthrough/vb.vbproj
(2) Normal C++ classes and functions can be used from managed .NET code by
providing thin wrapper classes written in MC++. The wrapper class will
take care of forwarding the calls to the normal C++ functions or
methods, and converting parameter data as necessary. Since the wrapper
class is a managed class, it can be used without further ado in any
managed .NET application, whether written in C#, VB.NET, MC++ or other
managed programming language.
The Qt class has nothing unusual for Qt users, and as even the Qt
specialities like Q_PROPERTY, slots and signals are
implemented with straight C++ they don't cause any trouble when
compiling this class with any C++ compiler.
The .NET wrapper class uses keywords that are part of MC++ to indicate
that the class is managed/garbage collected (__gc), and that StatusString should be accessible as a property in languages that
support this concept (__property). We also declare an event
function statusStringChanged(String*) (__event), the
equivalent of the respective signal in the Qt class.
Before we can start implementing the wrapper class we need a way to
convert Qt's datatypes (and potentionally your own) into .NET
datatypes, e.g. QString objects need to be converted into objects
of type String*.
When operating on managed objects in normal C++ code, a little extra
care must be taken because of the CLR's garbage collection. A normal
pointer variable should not (3) However, two methods are provided that solves this problem easily. The
first is to use a pinned pointer, i.e. declare the pointer variable
with the __pin keyword. This guarantees that the object pointed to
will not be moved by the garbage collector. It is recommended that
this method not be used to keep a references to managed objects for a
long time, since it will decrease the efficiency of the garbage
collector. The second way is to use the gcroot smartpointer
template type. This lets you create safe pointers to managed
objects. E.g. a variable of type gcroot<String> will always point
to the String object, even if it has been moved by the garbage
collector, and it can be used just like a normal pointer.
The convertor functions can then be used in the wrapper class
implementation to call the functions in the native C++ class.
The constructor and destructor simply create and destroy the Qt
object wrapped using the C++ operators new and delete.
The netWorker class delegates calls from the .NET code to the native
code. Although the transition between those two worlds implies a small
performance hit for each function call, and for the type conversion,
this should be negligible since we are anyway going to run within the
CLR.
The property setter calls the native Qt class before firing the
event using the __raise keyword.
This wrapper class can now be used in .NET code, e.g. using C++, C#,
Visual Basic or any other programming language available for .NET.
Fortunately .NET provides a generic wrapper for COM objects, the
Runtime Callable Wrapper (RCW). This RCW is a proxy for the
COM object and is generated by the CLR when a .NET Framework client
activates a COM object. This provides a generic way to reuse COM
objects in a .NET Framework project.
Making a QObject class into a COM object is easily achieved with
ActiveQt and demonstrated in the examples. The walkthrough will use the Qt classes implemented
in those examples, so the first thing to do is to make sure that those
examples have been built correctly, e.g. by opening the demonstration pages in Internet
Explorer to verify that the controls are functional.
Start Visual Studio.NET, and create a new C# project for writing a
Windows application. This will present you with an empty form in
Visual Studio's dialog editor. You should see the toolbox, which
presents you with a number of available controls and objects in
different categories. If you right-click on the toolbox it allows
you to add new tabs. We will add the tab "Qt".
The category only has a pointer tool by default, and we have to add
the Qt objects we want to use in our form. Right-click on the empty
space, and select "Customize". This opens a dialog that has two
tabs, "COM Components" and ".NET Framework Components". We used
ActiveQt to wrap QWidgets into COM objects, so we select the "COM
Components" page, and look for the classes we want to use, e.g.
"QPushButton" and "QAxWidget2".
When we select those widgets and close the dialog the two widgets
will now be available from the toolbox as grey squares with their
name next to it (4) We can now add an instance of QAxWidget2 and a QPushButton to
the form. Visual Studio will automatically generate the RCW for the
object servers. The QAxWidget2 instance takes most of the upper
part of the form, with the QPushButton in the lower right corner.
In the property editor of Visual Studio we can modify the properties
of our controls - QPushButton exposes the QWidget API and has many
properties, while QAxWidget2 has only the Visual Studio standard
properties in addition to its own property "lineWidth" in the
"Miscellaneous" category. The objects are named "axQPushButton1" and
"axQAxWidget21", and since especially the last name is a bit
confusing we rename the objects to "resetButton" and "circleWidget".
We can also change the Qt properties, e.g. set the "text" property
of the resetButton to "Reset", and the "lineWidth" property of the
circleWidget to 5. We can also put those objects into the layout
system that Visual Studio's dialog editor provides, e.g. by setting
the anchors of the circleWidget to "Left, Top, Right, Bottom", and
the anchors of the resetButton to "Bottom, Right".
Now we can compile and start the project, which will open a user
interface with our two Qt widgets. If we can resize the dialog,
the widgets will resize appropriately.
We will now implement event handlers for the widgets. Select the
circleWidget and select the "Events" page in the property
editor. The widget exposes events because the QAxWidget2 class has
the "StockEvents" attribute set in its class definition. We implement
the event handler circleClicked for the ClickEvent to increase
the line width by one for every click:
In general we can implement a default event handler by double
clicking on the widget in the form, but the default events for
our widgets are right now not defined.
We will also implement an event handler for the clicked signal
emitted by QPushButton. Add the event handler resetLineWidth to
the clicked event, and implement the generated function:
We reset the property to 1, and also call the setFocus() slot
to simulate the user style on Windows, where a button grabs focus
when you click it (so that you can click it again with the spacebar).
If we now compile and run the project we can click on the circle
widget to increase its line width, and press the reset button to
set the line width back to 1.
Using ActiveQt as a universal interoperability bridge between the
.NET world and the native world of Qt is very easy, and makes it
often unnecessary to implement a lot of handwritten wrapper classes.
Instead, the QAxFactory implementation in the otherwise completely
cross-platform Qt project provides the glue that .NET needs to to
generate the RCW.
If this is not sufficient we can implement our own wrapper classes
thanks to the C++ extensions provided by Microsoft.
All the limitations when using ActiveQt are implied when using this
technique to interoperate with .NET, e.g. the datatypes we can use
in the APIs can only be those supported by ActiveQt and COM. However,
since this includes subclasses of QObject and QWidget we can wrap
any of our datatypes into a QObject subclass to make its API
available to .NET. This has the positive side effect that the same
API is automatically available in QSA, the cross platform
scripting solution for Qt applications, and to COM clients in general.
When using the "IJW" method, in priciple the only limitation is the
time required to write the wrapper classes and data type conversion
functions.
Every call from CLR bytecode to native code implies a small
performance hit, and necessary type conversions introduce an
additional delay with every layer that exists between the two
frameworks. Consequently every approach to mix .NET and native
code should try to minimize the communication necessary between
the different worlds.
As ActiveQt introduces three layers at once - the RCW, COM and finally
ActiveQt itself - the performance penalty when using the generic
Qt/ActiveQt/COM/RCW/.NET bridge is larger than when using a
hand-crafted IJW-wrapper class. The execution speed however is still
sufficient for connecting to and modifying interactive elements in a
user interface, and as soon as the benefit of using Qt and C++ to
implement and compile performance critical algorithms into native code
kicks in, ActiveQt becomes a valid choice for making even non-visual
parts of your application accessible to .NET.
See also The QAxServer Examples.
|
Publicité
Best OfActualités les plus luesSemaine
Mois
Année
Le Qt Labs au hasardLe moteur de rendu RasterLes Qt Labs sont les laboratoires des développeurs de Qt, où ils peuvent partager des impressions sur le framework, son utilisation, ce que pourrait être son futur. Lire l'article.
CommunautéRessources
Liens utilesContact
Qt dans le magazine |
Cette page est une traduction d'une page de la documentation de Qt, écrite par Nokia Corporation and/or its subsidiary(-ies). Les éventuels problèmes résultant d'une mauvaise traduction ne sont pas imputables à Nokia. | Qt 3.3 | |
Copyright © 2012 Developpez LLC. Tous droits réservés Developpez LLC. Aucune reproduction, même partielle, ne peut être faite de ce site et de l'ensemble de son contenu : textes, documents et images sans l'autorisation expresse de Developpez LLC. Sinon, vous encourez selon la loi jusqu'à 3 ans de prison et jusqu'à 300 000 E de dommages et intérêts. Cette page est déposée à la SACD. | ||
Vous avez déniché une erreur ? Un bug ? Une redirection cassée ? Ou tout autre problème, quel qu'il soit ? Ou bien vous désirez participer à ce projet de traduction ? N'hésitez pas à nous contacter ou par MP ! |
Copyright © 2000-2012 - www.developpez.com