summaryrefslogtreecommitdiffstats
path: root/doc/object.doc
diff options
context:
space:
mode:
authorMichele Calgaro <[email protected]>2023-09-23 12:42:20 +0900
committerMichele Calgaro <[email protected]>2023-09-23 12:42:20 +0900
commitb35e0845dc9b3c8b9a5e52a682c769f383933fae (patch)
treee4eeca8f6fe0ca87e774be98eabf89b4c7fca347 /doc/object.doc
parent1ba13366a7a377d50b9e8df9044ce11d8209f98c (diff)
downloadtqt3-b35e0845dc9b3c8b9a5e52a682c769f383933fae.tar.gz
tqt3-b35e0845dc9b3c8b9a5e52a682c769f383933fae.zip
Replace QObject, QWidget, QImage, QPair, QRgb, QColor, QChar, QString, QIODevice with TQ* version
Signed-off-by: Michele Calgaro <[email protected]>
Diffstat (limited to 'doc/object.doc')
-rw-r--r--doc/object.doc94
1 files changed, 47 insertions, 47 deletions
diff --git a/doc/object.doc b/doc/object.doc
index 79e75c50d..f38389d02 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.
*/