| Home | All Classes | Main Classes | Annotated | Grouped Classes | Functions | |
This document describes porting applications from TQt 2.x to TQt 3.x.
The TQt 3.x series is not binary compatible with the 2.x series. This means programs compiled for TQt 2.x must be recompiled to work with TQt 3.x. TQt 3.x is also not completely source compatible with 2.x, however all points of incompatibility cause compiler errors or run-time messages (rather than mysterious results). TQt 3.x includes many additional features and discards obsolete functionality. Porting from TQt 2.x to TQt 3.x is straightforward, and once completed makes the considerable additional power and flexibility of TQt 3.x available for use in your applications.
To port code from TQt 2.x to TQt 3.x:
Table of contents:
On Windows, originally in TQt 2.x, the default configuration of the TQt library is static. If you just use the default configuration you don't need to set certain preprocessor defines. In TQt 3.0, the default configuration of the TQt library is to build it as a shared library, therefore the preprocessor define QT_DLL is needed.
If you use tmake with TQt 2.x, and now use qmake with TQt 3.x, then the cause of the problem is with the project file. In the project file, there is usually line that looks like:
CONFIG = ...
this should be changed to
CONFIG += ...
so that qmake can look at the configuration that TQt was built with and set any relevant preprocessor defines in the makefile.
TQt 3.x remove some unnecessary nested #include directives from header files. This speeds up compilation when you don't need those nested header files. But in some cases you will find you need to add an extra #include to your files.
For example, if you get a message about TQStringList or its functions not being defined, then add #include <qstringlist.h> at the top of the file giving the error.
Header files that you might need to add #include directives for include:
TQt 3.x is namespace clean. A few global identifiers that had been left in TQt 2.x have been discarded.
Enumeration TQt::CursorShape and its values are now part of the special TQt class defined in qnamespace.h. If you get compilation errors about these being missing (unlikely, since most of your code will be in classes that inherit from the TQt namespace class), then apply the following changes:
The names of some debugging macro variables have been changed. We have tried not to break source compatibility as much as possible. If you observe error messages on the UNIX console or the Windows debugging stream that were previously disabled, please check these macro variables:
The name of some debugging macro functions has been changed as well but source compatibility should not be affected if the macro variable QT_CLEAN_NAMESPACE is not defined:
For the record, undocumented macro variables that are not part of the API have been changed:
All these functions have been removed in TQt 3.x:
Also, to avoid conflicts with <iostream>, the following three global functions have been renamed:
The following functions have been obsoleted in TQt 3.0. The documentation of each of these functions should explain how to replace them in TQt 3.0.
Warning: It is best to consult http://doc.trolltech.com/3.0/ rather than the documentation supplied with TQt to obtain the latest information regarding obsolete functions and how to replace them in new code.
Additionally, these preprocessor directives have been removed:
See the changes-3.0.0 document for an explanation of why this had to be done. You might have been relying on the non-portable and unpredictable behavior resulting from these directives. We strongly recommend that you either make use of the safe qstr* variants directly or ensure that no 0 pointer is passed to the standard C functions in your code base.
The classes TQArray, TQCollection, TQList, TQListIterator, TQQueue, TQStack and TQVector have been renamed. To ease porting, the old names and the old header-file names are still supported.
| Old Name | New Name | New Header File |
|---|---|---|
| TQArray | TQMemArray | <qmemarray.h> |
| TQCollection | TQPtrCollection | <qptrcollection.h> |
| TQList | TQPtrList | <qptrlist.h> |
| TQListIterator | TQPtrListIterator | <qptrlist.h> |
| TQQueue | TQPtrQueue | <qptrqueue.h> |
| TQStack | TQPtrStack | <qptrstack.h> |
| TQVector | TQPtrVector | <qptrvector.h> |
In TQt 2.x, the function TQButtonGroup::selected() returns the selected radio button (TQRadioButton). In TQt 3.0, it returns the selected toggle button (TQButton::toggleButton), a more general concept. This might affect programs that use TQButtonGroups that contain a mixture of radio buttons and non-radio (e.g. TQCheckBox) toggle buttons.
Two TQDate member functions that were virtual in TQt 2.0 are not virtual in TQt 3.0. This is only relevant if you subclassed TQDate and reimplemented these functions:
In addition to no longer being virtual, TQDate::monthName() and TQDate::dayName() have been renamed TQDate::shortMonthName() and TQDate::shortDayName() and have been made static (as they should had been in the first place). The old names are still provided for source compatibility.
If the mode was not set explicitly, and the user entered a non-existent file, the dialog would accept this. In TQt 3.x, you must set the mode, e.g. setMode(TQFileDialog::AnyFile), to get the same behavior.
The internals of TQFont have changed significantly between TQt 2.2 and TQt 3.0, to give better Unicode support and to make developing internationalized applications easier. The original API has been preserved with minimal changes. The CharSet enum and its related functions have disappeared. This is because TQt now handles all charset related issues internally, and removes this burden from the developer.
If you used the CharSet enum or its related functions, e.g TQFont::charSet() or TQFont::setCharSet(), just remove them from your code. There are a few functions that took a TQFont::CharSet as a parameter; in these cases simply remove the charset from the parameter list.
The two static getText(...) methods in TQInputDialog have been merged. The echo parameter is the third parameter and defaults to TQLineEdit::Normal.
If you used calls to TQInputDialog::getText(...) that provided more than the first two retquired parameters you will must add a value for the echo parameter.
The definitions of TQGLayoutIterator, TQLayout, TQLayoutItem, TQLayoutIterator, TQSpacerItem and TQWidgetItem have been moved from <qabstractlayout.h> to <qlayout.h>. The header <qabstractlayout.h> now includes <qlayout.h> for compatibility. It might be removed in a future version.
The paintBranches() function in TQt 2.x had a GUIStyle parameter; this has been dropped for TQt 3.x since GUI style is handled by the new style engine (See TQStyle.)
In TQt 2.x, the function TQMoveEvent::pos() returned the position of the widget in its parent widget, including the window frame. In TQt 3.0, it returns the new position of the widget, excluding window frame for top level widgets.
The TQMultiLineEdit was a simple editor widget in previous TQt versions. Since TQt 3.0 includes a new richtext engine, which also supports editing, TQMultiLineEdit is obsolete. For the sake of compatibility TQMultiLineEdit is still provided. It is now a subclass of TQTextEdit which wraps the old TQMultiLineEdit so that it is mostly source compatible to keep old applications working.
For new applications and when maintaining existing applications we recommend that you use TQTextEdit instead of TQMultiLineEdit wherever possible.
Although most of the old TQMultiLineEdit API is still available, there is one important difference. The old TQMultiLineEdit operated in terms of lines, whereas TQTextEdit operates in terms of paragraphs. This is because lines change all the time during wordwrap, whereas paragraphs remain paragraphs. The consequence of this change is that functions which previously operated on lines, e.g. numLines(), textLine(), etc., now work on paragraphs.
Also the function getString() has been removed since it published the internal data structure.
In most cases, applications that used TQMultiLineEdit will continue to work without problems. Applications that worked in terms of lines may retquire some porting.
The source code for the old 2.x version of TQMultiLineEdit can be found in $QTDIR/src/attic/qtmultilineedit.h/cpp. Note that the class has been renamed to TQtMultiLineEdit to avoid name clashes. If you really need to keep compatibility with the old TQMultiLineEdit, simply include this class in your project and rename TQMultiLineEdit to TQtMultiLineEdit throughout.
TQPrinter has undergone some changes, to make it more flexible and to ensure it has the same runtime behaviour on both Unix and Windows. In 2.x, TQPrinter behaved differently on Windows and Unix, when using view transformations on the TQPainter. This has changed now, and TQPrinter behaves consistently across all platforms. A compatibilty mode has been added that forces the old behaviour, to ease porting from TQt 2.x to TQt 3.x. This compatibilty mode can be enabled by passing the TQPrinter::Compatible flag to the TQPrinter constructor.
On X11, TQPrinter used to generate encapsulated postscript when fullPage() was TRUE and only one page was printed. This does not happen by default anymore, providing a more consistent printing output.
The TQRegExp class has been rewritten to support many of the features of Perl regular expressions. Both the regular expression syntax and the TQRegExp interface have been modified.
Be also aware that <qregexp.h> is no longer included automatically when you include <qstringlist.h>. See above for details.
There are five new special characters: (, ), {, | and } (parentheses, braces and pipe). When porting old regular expressions, you must add \ (backslash) in front of any of these (actually, \\ in C++ strings), unless it is already there.
Example: Old code like
TQRegExp rx( "([0-9|]*\\)" ); // works in TQt 2.x
should be converted into
TQRegExp rx( "\\([0-9\\|]*\\)" ); // works in TQt 2.x and 3.x
(Within character classes, the backslash is not necessary in front of certain
characters, e.g. |, but it doesn't hurt.)
Wildcard patterns need no conversion. Here are two examples:
TQRegExp wild( "(*.*)" );
wild.setWildcard( TRUE );
// TRUE as third argument means wildcard
TQRegExp wild( "(*.*)", FALSE, TRUE );
However, when they are used, make sure to use TQRegExp::exactMatch()
rather than the obsolete TQRegExp::match(). TQRegExp::match(), like
TQRegExp::find(), tries to find a match somewhere in the target
string, while TQRegExp::exactMatch() tries to match the whole target
string.
This function has been replaced by TQRegExp::setPattern() in TQt 2.2. Old code such as
TQRegExp rx( "alpha" );
rx.setCaseSensitive( FALSE );
rx.setWildcard( TRUE );
rx = "beta";
still compiles with TQt 3, but produces a different result (the case sensitivity
and wildcard options are forgotten). This way,
rx = "beta";
is the same as
rx = TQRegExp( "beta" );
which is what one expects.
The following function is now obsolete, as it has an unwieldy parameter list and was poorly named:
This function was removed, after a brief appearance in TQt 2.2. Its name clashed with TQString::find(). Use TQRegExp::search() or TQString::find() instead.
TQString::findRev()'s and TQString::contains()'s semantics have changed between 2.0 and 3.0 to be more consistent with the other overloads.
For example,
TQString( "" ).contains( TQRegExp("") )
returns 1 in TQt 2.0; it returns 0 in TQt 3.0. Also, "^" now really means
start of input, so
TQString( "Heisan Hoppsan" ).contains( TQRegExp("^.*$") )
returns 1, not 13 or 14.
This change affect very few existing programs.
With TQt 1.0 and 2.0, a TQString is converted implicitly into a TQRegExp as the first argument to TQString::replace():
TQString text = fetch_it_from_somewhere();
text.replace( TQString("[A-Z]+"), "" );
With TQt 3.0, the compiler gives an error. The solution is to use a
TQRegExp cast:
text.replace( TQRegExp("[A-Z]+"), "" );
This change makes it possible to introduce a
TQString::replace(TQString, TQString) overload in a future version of TQt
without breaking source compatibility.
The TQSemiModal class is now obsolete. You should call show() on a modal dialog instead.
The TQSortedList class is now obsolete. Consider using a TQDict, a TQMap or a plain TQPtrList instead.
The TQTableView class has been obsoleted and is no longer a part of the TQt API. Either use the powerful TQTable class or the simplistic TQGridView in any new code you create. If you really need the old table view for compatibility you can find it in $QTDIR/src/attic/qttableview.{cpp,h}. Note that the class has been renamed from TQTableView to TQtTableView to avoid name clashes. To use it, simply include it in your project and rename TQTableView to TQtTableView throughout.
The TQToolButton class used to distinguish between "on" and "off" icons. In 3.0, this mechanism was moved into the TQIconSet class (see TQIconSet::State).
The old TQToolButton::onIconSet and TQToolButton::offIconSet properties are still provided so that old source will compile, but their semantics have changed: they are now synonyms for TQToolButton::iconSet. If you used that distinction in TQt 2.x, you will need to adjust your code to use the TQIconSet On/Off mechanism.
Likewise, the on parameter of these two functions is now ignored:
These functions are only provided for ease of porting. New code should use the following instead:
Finally, this function is no longer virtual:
If you have a class that inherits TQToolButton and that reimplements TQToolButton::setIconSet(), you should make the signature of the reimplementation agree with the new TQToolButton::setIconSet(), a virtual function.
The global TQTextStream manipulators setw(), setfill() and setprecison() were renamed to qSetW(), qSetFill() and qSetPrecision() to avoid conflicts with <iostream.h>. If you used them, you must rename the occurrences to the new names.
The TQTranslator class was extended in TQt 2.2, and these extensions lead to a new interface. This interface is used mainly by translation tools (for example, TQt Linguist). For source compatibility, no member function was effectively removed. The TQTranslator documentation points out which functions are obsolete.
This function is no longer virtual:
If you have a class that inherits TQTranslator and which reimplements TQTranslator::find(), you should reimplement TQTranslator::findMessage() instead. In fact, find() is now defined in terms of findMessage(). By doing the conversion, you will also gain support for translator comments and for any future extensions.
TQWidget::backgroundColor(), TQWidget::setBackgroundColor(), TQWidget::backgroundPixmap() and TQWidget::setBackgroundPixmap() have often been the source of much confusion in previous releases. TQt 3.0 addresses this by obsoleting these functions and by replacing them with eight new functions: TQWidget::eraseColor(), TQWidget::setEraseColor(), TQWidget::erasePixmap(), TQWidget::setErasePixmap(), TQWidget::paletteBackgroundColor(), TQWidget::setPaletteBackgroundColor(), TQWidget::paletteBackgroundPixmap() and TQWidget::setPaletteBackgroundPixmap(). See their documentation for details.
The semantics of TQXmlInputSource has changed slightly. This change only affects code that parses the same data from the same input source multiple times. In such cases you must call TQXmlInputSource::reset() before the second call to TQXmlSimpleReader::parse().
So code like
TQXmlInputSource source( &xmlFile );
TQXmlSimpleReader reader;
...
reader.parse( source );
...
reader.parse( source );
must be changed to
TQXmlInputSource source( &xmlFile );
TQXmlSimpleReader reader;
...
reader.parse( source );
...
source.reset();
reader.parse( source );
Due to some internal changes, it was necessary to clean-up the semantics of TQXmlLocator: this class is now an abstract class. This shouldn't cause any problems, since programmers usually used the TQXmlLocator that was reported by TQXmlContentHandler::setDocumentLocator(). If you used this class in some other way, you must adjust your code to use the TQXmlLocator that is reported by the TQXmlContentHandler::setDocumentLocator() function.
TQASyncIO, TQDataSink, TQDataSource, TQIODeviceSource and TQDataPump were used internally in previous versions of TQt, but are not used anymore. They are now obsolete.
In TQt 2.x, the AutoMask property was used to obtain a transparent-looking widget. In general, this approach is slow and processor hungry. TQt 3.0 uses the BackgroundOrigin which provides vastly improved performance and more flexibility in most cases. The few classes for which the AutoMask property is still the best approach are TQCheckBox, TQComboBox, TQPushButton, TQRadioButton and TQTabWidget.
The function names for Bezier curves in TQPainter and TQPointArray have been corrected. They now properly reflect their cubic form instead of a quadratic one. If you have been using either TQPainter::drawQuadBezier() or TQPointArray::quadBezier() you must replace these calls with
In TQt 2.x, TQString only provided string comparisons using the Unicode values of the characters of a string. This is efficient and reliable, but it is not the appropriate order for most languages. For example, French users expect 'é' (e acute) to be treated essentially as 'e' and not put after 'z'.
In TQt 3.0, TQString::localeAwareCompare() implements locale aware string comparisions on certain platforms. The classes TQIconView, TQListBox, TQListView and TQTable now use TQString::localeAwareCompare() instead of TQString::compare(). If you want to control the behaviour yourself you can always reimplement TQIconViewItem::compare(), TQListBox::text(), TQListViewItem::compare() or TQTableItem::key() as appropriate.
| Copyright © 2007 Trolltech | Trademarks | TQt 3.3.8
|