| Home | All Classes | Main Classes | Annotated | Grouped Classes | Functions | |
The TQAxWidget class is a TQWidget that wraps an ActiveX control. More...
This class is part of the TQt ActiveTQt Extension.
#include <qaxwidget.h>
Inherits TQWidget and TQAxBase.
This class is defined in the TQt ActiveTQt Extension, which can be found in the qt/extensions directory. It is not included in the main TQt API.
The TQAxWidget class is a TQWidget that wraps an ActiveX control.
A TQAxWidget can be instantiated as an empty object, with the name of the ActiveX control it should wrap, or with an existing interface pointer to the ActiveX control. The ActiveX control's properties, methods and events which only use supported data types, become available as TQt properties, slots and signals. The base class TQAxBase provides an API to access the ActiveX directly through the IUnknown pointer.
TQAxWidget is a TQWidget and can be used as such, e.g. it can be organized in a widget hierarchy, receive events or act as an event filter. Standard widget properties, e.g. enabled are supported, but it depends on the ActiveX control to implement support for ambient properties like e.g. palette or font. TQAxWidget tries to provide the necessary hints.
Warning: You can subclass TQAxWidget, but you cannot use the TQ_OBJECT macro in the subclass (the generated moc-file will not compile), so you cannot add further signals, slots or properties. This limitation is due to the metaobject information generated in runtime. To work around this problem, aggregate the TQAxWidget as a member of the TQObject subclass.
See also control.
See also clear().
This function is called by initialize(). If you reimplement initialize to customize the actual control instantiation, call this function in your reimplementation to have the control embedded by the default client side. Creates the client site for the ActiveX control, and returns TRUE if the control could be embedded successfully, otherwise returns FALSE.
If function is a method of the object the string must be provided as the full prototype, for example as it would be written in a TQObject::connect() call.
activeX->dynamicCall( "Navigate(const TQString&)", "www.trolltech.com" );
Alternatively a function can be called passing the parameters embedded in the string, e.g. above function can also be invoked using
activeX->dynamicCall("Navigate(\"www.trolltech.com\");
All parameters are passed as strings; it depends on the control whether
they are interpreted correctly, and is slower than using the prototype
with correctly typed parameters.
If function is a property the string has to be the name of the property. The property setter is called when var1 is a valid TQVariant, otherwise the getter is called.
activeX->dynamicCall( "Value", 5 );
TQString text = activeX->dynamicCall( "Text" ).toString();
Note that it is faster to get and set properties using
TQObject::property() and TQObject::setProperty().
It is only possible to call functions through dynamicCall() that have parameters or return values of datatypes supported by TQVariant. See the TQAxBase class documentation for a list of supported and unsupported datatypes. If you want to call functions that have unsupported datatypes in the parameter list, use queryInterface() to retrieve the appropriate COM interface, and use the function directly.
IWebBrowser2 *webBrowser = 0;
activeX->queryInterface( IID_IWebBrowser2, (void**)&webBrowser );
if ( webBrowser ) {
webBrowser->Navigate2( pvarURL );
webBrowser->Release();
}
This is also more efficient.
Example: qutlook/centralwidget.cpp.
Calls the COM object's method function, passing the parameters in vars, and returns the value returned by the method. If the method does not return a value or when the function call failed this function returns an invalid TQVariant object.
The TQVariant objects in vars are updated when the method has out-parameters.
If name is provided by a method the string must include the full function prototype.
If name is a property the string must be the name of the property, and var1, ... var8 are ignored.
The returned TQAxObject is a child of this object (which is either of type TQAxObject or TQAxWidget), and is deleted when this object is deleted. It is however safe to delete the returned object yourself, and you should do so when you iterate over lists of subobjects.
COM enabled applications usually have an object model publishing certain elements of the application as dispatch interfaces. Use this method to navigate the hierarchy of the object model, e.g.
TQAxWidget outlook( "Outlook.Application" );
TQAxObject *session = outlook.querySubObject( "Session" );
if ( session ) {
TQAxObject *defFolder = session->querySubObject(
"GetDefaultFolder(OlDefaultFolders)",
"olFolderContacts" );
//...
}
Example: qutlook/centralwidget.cpp.
If the function returns TRUE the key event is passed on to the ActiveX control, which then either processes the event or passes the event on to TQt.
If the function returns FALSE the processing of the key event is ignored by ActiveTQt, ie. the ActiveX control might handle it or not.
The default implementation returns TRUE for the following cases:
| WM_SYSKEYDOWN | WM_SYSKEYUP | WM_KEYDOWN |
|---|---|---|
| All keycodes | VK_MENU | VK_TAB, VK_DELETE and all non-arrow-keys in combination with VK_SHIFT, VK_CONTROL or VK_MENU |
This table is the result of experimenting with popular ActiveX controls, ie. Internet Explorer and Microsoft Office applications, but for some controls it might require modification.
This file is part of the TQt toolkit. Copyright © 1995-2007 Trolltech. All Rights Reserved.
| Copyright © 2007 Trolltech | Trademarks | TQt 3.3.8
|