diff options
Diffstat (limited to 'doc/object.doc')
| -rw-r--r-- | doc/object.doc | 94 |
1 files changed, 47 insertions, 47 deletions
diff --git a/doc/object.doc b/doc/object.doc index 79e75c50..f38389d0 100644 --- a/doc/object.doc +++ b/doc/object.doc @@ -69,7 +69,7 @@ Qt adds these features to C++: \endlist Many of these TQt features are implemented with standard C++ -techniques, based on inheritance from \l QObject. Others, like the +techniques, based on inheritance from \l TQObject. Others, like the object communication mechanism and the dynamic property system, require the \link metaobjects.html Meta Object System \endlink provided by Qt's own \link moc.html Meta Object Compiler (moc) \endlink. @@ -91,11 +91,11 @@ slots? \endlink. \title Timers -\l QObject, the base class of all TQt objects, provides the basic timer -support in Qt. With \l QObject::startTimer(), you start a timer with +\l TQObject, the base class of all TQt objects, provides the basic timer +support in Qt. With \l TQObject::startTimer(), you start a timer with an \e interval in milliseconds as argument. The function returns a unique integer timer id. The timer will now "fire" every \e interval -milliseconds, until you explicitly call \l QObject::killTimer() with +milliseconds, until you explicitly call \l TQObject::killTimer() with the timer id. For this mechanism to work, the application must run in an event @@ -114,7 +114,7 @@ can handle 1 millisecond intervals. The main API for the timer functionality is \l QTimer. That class provides regular timers that emit a signal when the timer fires, and -inherits \l QObject so that it fits well into the ownership structure +inherits \l TQObject so that it fits well into the ownership structure of most GUI programs. The normal way of using it is like this: \code QTimer * counter = new QTimer( this ); @@ -147,16 +147,16 @@ single-threaded application without blocking the user interface. \code // The Mandelbrot class uses a QTimer to calculate the mandelbrot // set one scanline at a time without blocking the CPU. It - // inherits QObject to use signals and slots. Calling start() + // inherits TQObject to use signals and slots. Calling start() // starts the calculation. The done() signal is emitted when it // has finished. Note that this example is not complete, just an // outline. - class Mandelbrot : public QObject + class Mandelbrot : public TQObject { TQ_OBJECT // required for signals/slots public: - Mandelbrot( QObject *parent=0, const char *name ); + Mandelbrot( TQObject *parent=0, const char *name ); ... public slots: void start(); @@ -173,8 +173,8 @@ single-threaded application without blocking the user interface. // Constructs and initializes a Mandelbrot object. // - Mandelbrot::Mandelbrot( QObject *parent=0, const char *name ) - : QObject( parent, name ) + Mandelbrot::Mandelbrot( TQObject *parent=0, const char *name ) + : TQObject( parent, name ) { connect( &timer, SIGNAL(timeout()), SLOT(calculate()) ); ... @@ -225,7 +225,7 @@ through \link signalsandslots.html signals and slots\endlink. The \c TQ_PROPERTY macro in a class declaration declares a property. Properties can only be declared in classes that inherit \l -QObject. A second macro, \c TQ_OVERRIDE, can be used to override some +TQObject. A second macro, \c TQ_OVERRIDE, can be used to override some aspects of an inherited property in a subclass. (See \link #override TQ_OVERRIDE\endlink.) @@ -237,16 +237,16 @@ ordinary data members: \i A read function. This always exists. \i A write function. This is optional: read-only properties like \l -QWidget::isDesktop() do not have one. +TQWidget::isDesktop() do not have one. \i An attribute "stored" that indicates persistence. Most properties are stored, but a few virtual properties are not. For example, \l -QWidget::minimumWidth() isn't stored, since it's just a view of -\l QWidget::minimumSize(), and has no data of its own. +TQWidget::minimumWidth() isn't stored, since it's just a view of +\l TQWidget::minimumSize(), and has no data of its own. \i A reset function to set a property back to its context specific -default value. This is very rare, but for example, \l QWidget::font() -needs this, since no call to \l QWidget::setFont() can mean 'reset to +default value. This is very rare, but for example, \l TQWidget::font() +needs this, since no call to \l TQWidget::setFont() can mean 'reset to the context specific font'. \i An attribute "designable" that indicates whether it makes sense to @@ -262,11 +262,11 @@ The read, write, and reset functions must be public member functions from the class in which the property is defined. Properties can be read and written through generic functions in -QObject without knowing anything about the class in use. These two +TQObject without knowing anything about the class in use. These two function calls are equivalent: \code - // QButton *b and QObject *o point to the same button + // QButton *b and TQObject *o point to the same button b->setDown( TRUE ); o->setProperty( "down", TRUE ); \endcode @@ -274,12 +274,12 @@ function calls are equivalent: Equivalent, that is, except that the first is faster, and provides much better diagnostics at compile time. When practical, the first is better. However, since you can get a list of all available properties -for any QObject through its \l QMetaObject, \l QObject::setProperty() +for any TQObject through its \l QMetaObject, \l TQObject::setProperty() can give you control over classes that weren't available at compile time. -As well as QObject::setProperty(), there is a corresponding \l -QObject::property() function. \l QMetaObject::propertyNames() returns +As well as TQObject::setProperty(), there is a corresponding \l +TQObject::property() function. \l QMetaObject::propertyNames() returns the names of all available properties. \l QMetaObject::property() returns the property data for a named property: a \l QMetaProperty object. @@ -288,11 +288,11 @@ Here's a simple example that shows the most important property functions in use: \code - class MyClass : public QObject + class MyClass : public TQObject { TQ_OBJECT public: - MyClass( QObject * parent=0, const char * name=0 ); + MyClass( TQObject * parent=0, const char * name=0 ); ~MyClass(); enum Priority { High, Low, VeryHigh, VeryLow }; @@ -324,7 +324,7 @@ registered with the property system as well. There are two exceptions to the above: The type of a property can also be either \link QValueList QValueList\<QVariant\>\endlink or \link -QMap QMap\<QString,QVariant\>\endlink. In +QMap QMap\<TQString,QVariant\>\endlink. In these cases the type must be specified as \c QValueList or as \c QMap (i.e. without their template parameters). @@ -339,13 +339,13 @@ Enumeration types are registered with the \c TQ_ENUMS macro. Here's the final class declaration including the property related declarations: \code - class MyClass : public QObject + class MyClass : public TQObject { TQ_OBJECT TQ_PROPERTY( Priority priority READ priority WRITE setPriority ) TQ_ENUMS( Priority ) public: - MyClass( QObject * parent=0, const char * name=0 ); + MyClass( TQObject * parent=0, const char * name=0 ); ~MyClass(); enum Priority { High, Low, VeryHigh, VeryLow }; @@ -397,16 +397,16 @@ through the meta object, see \l QMetaObject::classInfo() for details. \target override \section1 TQ_OVERRIDE -When you inherit a QObject subclass you may wish to override some +When you inherit a TQObject subclass you may wish to override some aspects of some of the class's properties. -For example, in QWidget we have the autoMask property defined like +For example, in TQWidget we have the autoMask property defined like this: \code TQ_PROPERTY( bool autoMask READ autoMask WRITE setAutoMask DESIGNABLE false SCRIPTABLE false ) \endcode -But we need to make the auto mask property designable in some QWidget +But we need to make the auto mask property designable in some TQWidget subclasses. Similarly some classes will need this property to be scriptable (e.g. for QSA). This is achieved by overriding these features of the property in a subclass. In QCheckBox, for example, we @@ -439,10 +439,10 @@ buttons. \title Events and Event Filters In Qt, an event is an object that inherits \l QEvent. Events are -delivered to objects that inherit \l QObject through calling \l -QObject::event(). Event delivery means that an event has occurred, the -QEvent indicates precisely what, and the QObject needs to respond. Most -events are specific to \l QWidget and its subclasses, but there are +delivered to objects that inherit \l TQObject through calling \l +TQObject::event(). Event delivery means that an event has occurred, the +QEvent indicates precisely what, and the TQObject needs to respond. Most +events are specific to \l TQWidget and its subclasses, but there are important events that aren't related to graphics, for example, socket activation, which is the event used by \l QSocketNotifier for its work. @@ -471,7 +471,7 @@ will explain enough for 99% of applications. The normal way for an event to be delivered is by calling a virtual function. For example, \l QPaintEvent is delivered by calling \l -QWidget::paintEvent(). This virtual function is responsible for +TQWidget::paintEvent(). This virtual function is responsible for reacting appropriately, normally by repainting the widget. If you do not perform all the necessary work in your implementation of the virtual function, you may need to call the base class's @@ -491,10 +491,10 @@ the base class. Occasionally there isn't such an event-specific function, or the event-specific function isn't sufficient. The most common example is -tab key presses. Normally, those are interpreted by QWidget to move +tab key presses. Normally, those are interpreted by TQWidget to move the keyboard focus, but a few widgets need the tab key for themselves. -These objects can reimplement \l QObject::event(), the general event +These objects can reimplement \l TQObject::event(), the general event handler, and either do their event handling before or after the usual handling, or replace it completely. A very unusual widget that both interprets tab and has an application-specific custom event might @@ -514,17 +514,17 @@ contain: // custom event handling here return TRUE; } - return QWidget::event( evt ); + return TQWidget::event( evt ); } \endcode More commonly, an object needs to look at another's events. Qt -supports this using \l QObject::installEventFilter() (and the +supports this using \l TQObject::installEventFilter() (and the corresponding remove). For example, dialogs commonly want to filter key presses for some widgets, e.g. to modify Return-key handling. An event filter gets to process events before the target object does. -The filter's \l QObject::eventFilter() implementation is called, and +The filter's \l TQObject::eventFilter() implementation is called, and can accept or reject the filter, and allow or deny further processing of the event. If all the event filters allow further processing of an event, the event is sent to the target object itself. If one of them @@ -556,7 +556,7 @@ postEvent() posts the event on a queue for later dispatch. The next time Qt's main event loop runs, it dispatches all posted events, with some optimization. For example, if there are several resize events, they are are compacted into one. The same applies to paint events: \l -QWidget::update() calls postEvent(), which minimizes flickering and +TQWidget::update() calls postEvent(), which minimizes flickering and increases speed by avoiding multiple repaints. postEvent() is also often used during object initialization, since the @@ -577,18 +577,18 @@ details. \title Object Trees and Object Ownership -\link QObject QObjects\endlink organize themselves in object trees. -When you create a QObject with another object as parent, it's added to -the parent's \link QObject::children() children() \endlink list, and +\link TQObject QObjects\endlink organize themselves in object trees. +When you create a TQObject with another object as parent, it's added to +the parent's \link TQObject::children() children() \endlink list, and is deleted when the parent is. It turns out that this approach fits the needs of GUI objects very well. For example, a \l QAccel (keyboard accelerator) is a child of the relevant window, so when the user closes that window, the accelerator is deleted too. -The static function \l QObject::objectTrees() provides access to all +The static function \l TQObject::objectTrees() provides access to all the root objects that currently exist. -\l QWidget, the base class of everything that appears on the screen, +\l TQWidget, the base class of everything that appears on the screen, extends the parent-child relationship. A child normally also becomes a child widget, i.e. it is displayed in its parent's coordinate system and is graphically clipped by its parent's boundaries. For example, @@ -603,8 +603,8 @@ toolbar it may lead to the application deleting one of its \l QToolBar objects, in which case the tool bar's \l QMainWindow parent would detect the change and reconfigure its screen space accordingly. -The debugging functions \l QObject::dumpObjectTree() and \l -QObject::dumpObjectInfo() are often useful when an application looks or +The debugging functions \l TQObject::dumpObjectTree() and \l +TQObject::dumpObjectInfo() are often useful when an application looks or acts strangely. */ |