From 23b535df5bc08e8f5e98270859c5dc5c73f4ebdd Mon Sep 17 00:00:00 2001 From: Michele Calgaro Date: Sun, 21 Oct 2018 19:05:32 +0900 Subject: Removed some obsolete code related to Qt1. Signed-off-by: Michele Calgaro --- doc/html/porting2.html | 965 ------------------------------------------------- 1 file changed, 965 deletions(-) delete mode 100644 doc/html/porting2.html (limited to 'doc/html/porting2.html') diff --git a/doc/html/porting2.html b/doc/html/porting2.html deleted file mode 100644 index 3402721cb..000000000 --- a/doc/html/porting2.html +++ /dev/null @@ -1,965 +0,0 @@ - - - - - -Porting to TQt 2.x - - - - - - - -
- -Home - | -All Classes - | -Main Classes - | -Annotated - | -Grouped Classes - | -Functions -

Porting to TQt 2.x

- - - -

-You're probably looking at this page because you want to port -your application from TQt 1.x to TQt 2.x, but to be sure, let's -review the good reasons to do this: -

-

-The TQt 2.x series is not binary compatible with the 1.x series. -This means programs compiled for TQt 1.x must be recompiled to work -with TQt 2.x. TQt 2.x is also not completely source compatible -with 1.x, however all points of incompatibility cause -compiler errors (rather than mysterious results), or produce run-time -messages. The result is that TQt 2.x includes many additional features, -discards obsolete functionality that is easily converted to use the new -features, and that porting an application from TQt 1.x to TQt 2.x is -a simple task well worth the amount of effort required. -

To port code using TQt 1.x to use TQt 2.x: -

-

Many very major projects, such as KDE -have been port, so there is plenty of expertise in the collective conscious -that is the TQt Developer Community! -

-

-

The Porting Notes

-

-

-

Namespace

-

TQt 2.x is namespace-clean, unlike 1.x. TQt now uses very few -global identifiers. Identifiers like red, blue, LeftButton, -AlignRight, Key_Up, Key_Down, NoBrush etc. are now part of a -special class TQt (defined in ntqnamespace.h), -which is inherited by -most TQt classes. Member functions of classes that inherit from TQWidget, -etc. are totally unaffected, but code that is -not in functions of classes inherited from TQt, -you must qualify these identifiers like this: TQt::red, -TQt::LeftButton, TQt::AlignRight, etc. -

The qt/bin/tqt20fix script helps to fix the code that -needs adaption, though most code does not need changing. -

Compiling with -DQT1COMPATIBILITY will help you get going with TQt 2.x -- it allows all the old "dirty namespace" identifiers from TQt 1.x to -continue working. Without it, you'll get compile errors that can -easily be fixed by searching this page for the clean identifiers. -

No Default 0 Parent Widget

-

In TQt 1.x, all widget constructors were defined with a default value -of 0 for the parent widget. However, only the main window of the -application should be created with a 0 parent, all other widgets -should have parents. Having the 0 default made it too simple to create -bugs by forgetting to specify the parent of non-mainwindow -widgets. Such widgets would typically never be deleted (causing memory -leaks), and they would become top-level widgets, confusing the window -managers. Therefore, in TQt 2.x the 0 default parent has been removed -for the widget classes that are not likely to be used as main windows. -

Note also that programs no longer need (or should) use 0 parent just -to indicate that a widget should be top-level. See -

 TQWidget::isTopLevel()
- for details. See also the notes about -TQPopupMenu and TQDialog -below. -

Virtual Functions

-

Some virtual functions have changed signature in TQt 2.x. -If you override them in derived classes, you must change the signature -of your functions accordingly. -

-

-

This is one class of changes that are -not detected by the compiler, -so you should mechanically search for each of -these function names in your header files, eg. -

-egrep -w 'setStyle|addColumn|setColumnText|setText...' *.h
-
- -

Of course, you'll get a few false positives (eg. if you have a setText -function that is not in a subclass of TQListViewItem). -

Collection classes

-

The collection classes include generic -classes such as TQGDict, TQGList, and -the subclasses such as TQDict and TQPtrList. -

The macro-based TQt collection classes are obsolete; use the -template-based classes instead. Simply remove includes of ntqgeneric.h and -replace e.g. Q_DECLARE(TQCache,TQPixmap) with TQCache. -

The GCI global typedef is replaced by TQCollection::Item. Only if you -make your own subclasses of the undocumented generic collection classes -will you have GCI in your code. -This change has been made to avoid collisions with other namespaces. -

The GCF global typedef is removed (it was not used in TQt). -

Debug vs. Release

-

The Q_ASSERT macro is now a null expression if the QT_CHECK_STATE flag -is not set (i.e. if the TQT_NO_CHECK flag is defined). -

The debug() function now outputs nothing if TQt was compiled with -the TQT_NO_DEBUG macro defined. -

TQString

-

TQString has undergone major changes internally, and although it is highly -backward compatible, it is worth studying in detail when porting to TQt 2.x. -The TQt 1.x TQString class has been renamed to TQCString in TQt 2.x, though if -you use that you will incur a performance penalty since all TQt functions -that took const char* now take const TQString&. -

-To take full advantage of the new Internationalization -functionality in TQt 2.x, the following steps are required: -

-

-Points to note about the new TQString are: -

-
Unicode
-
-TQt now uses Unicode throughout. -data() now returns a const reference to an ASCII version -of the string - you cannot directly access the -string as an array of bytes, because it isn't one. Often, latin1() is -what you want rather than data(), or just leave it to convert to -const char* automatically. data() is only used now to aide porting to TQt 2.x, -and ideally you'll only need latin1() or implicit conversion when interfacing -to facilities that do not have Unicode support. -

Automatic-expanding
-
-A big advantage of the new TQString is that it automatically expands -when you write to an indexed position. -

TQChar and TQCharRef
-
-TQChar are the Unicode characters that make up a TQString. A TQCharRef is -a temporary reference to a TQChar in a TQString that when assigned to -ensures that the implicit sharing semantics of the TQString are maintained. -You are unlikely to use TQCharRef in your own code - but so that you -understand compiler error messages, just know that mystring[123] -is a TQCharRef whenever mystring is not a constant string. A TQCharRef -has basically the same functionality as a TQChar, except it is more restricted -in what you can assign to it and cast it to (to avoid programming errors). -

Use TQString
-
-Try to always use TQString. If you must, use TQCString which is the -old implementation from TQt 1.x. -

Unicode vs. ASCII
-
-Every conversion to and from ASCII is wasted time, so try to use TQString -as much as possible rather than const char*. This also ensures you have -full 16-bit support. -

Convertion to ASCII
-
-The return value from operator const char*() is transient - don't expect -it to remain valid while you make deep function calls. -It is valid for as long as you don't modify or destroy the TQString. -

TQString is simpler
-
-Expect your code to become simpler with the new TQString, especially -places where you have used a char* to wander over the string rather -than using indexes into the string. -

Some hacks don't work
-
-This hack: -use_sub_string( &my_string[index] ) -should be replaced by: -use_sub_string( my_string.mid(index) ) -

TQString(const char*, int) is removed
-
-The TQString constructor taking a const char* and an integer is removed. -Use of this constructor was error-prone, since the length included the -'\0' terminator. Use TQString::left(int) or TQString::fromLatin1( const char*, -int ) -- in both cases the int parameter signifies the number of characters. -

TQString(int) is private
-
-The TQString constructor taking an integer is now private. This function -is not meaningful anymore, since TQString does all space allocation -automatically. 99% of cases can simple be changed to use the -default constructor, TQString(). -

-In TQt 1.x the constructor was used in two ways: accidentally, -by attempting to convert a char to a TQString (the char converts to int!) - -giving strange bugs, and as a way to make a TQString big enough prior to -calling 

 TQString::sprintf()
- . In TQt 2.x, the accidental bug case is -prevented (you will get a compilation error) and TQString::sprintf has -been made safe - you no longer need to pre-allocate space (though for -other reasons, sprintf is still a poor choice - eg. it doesn't pass Unicode). -The only remaining common case is conversion of 0 (NULL) to TQString, which -would usually give expected results in TQt 1.x. For TQt 2.x the correct -syntax is to use TQString::null, though note that -the default constructor, TQString(), creates a null string too. -Assignment of 0 to a TQString is ambiguous - assign -TQString::null; you'll mainly find these in code that has been converted -from const char* types to TQString. -This also prevents a common error case from TQt 1.x - in -that version, mystr = 'X' would not produce the expected -results and was always a programming error; in TQt 2.x, it works - making -a single-character string. -

-Also see TQStrList. -

Signals and Slots
-
-Many signal/slots have changed from const char* to TQString. You will -get run-time errors when you try to 
 TQObject::connect()
- -to the old -signals and slots, usually with a message indicating the const TQString& -replacement signal/slot. -

Optimize with Q2HELPER
-
-In qt/src/tools/qstring.cpp there is a Q2HELPER - define it for some -extra debugging/optimizing features (don't leave it it - it kills performance). -You'll get an extra function, qt_qstring_stats(), which will print a -summary of how much your application is doing Unicode and ASCII -back-and-forth conversions. -

TQString::detach() is obsolete and removed
-
-Since TQString is now always shared, this function does nothing. -Remove calls to TQString::detach(). -

TQString::resize(int size) is obsolete and removed
-
-Code using this to truncate a string should use -truncate(size-1). -Code using qstr.resize(0) should use qstr = TQString::null. -Code calling resize(n) prior to using -operator[] up to n just remove -the resize(n) completely. -

TQString::size() is obsolete and removed
-
-Calls to this function must be replaced by -length()+1. -

TQString::setStr(const char*) is removed
-
Try to understand why you were using this. -If you just meant assignment, use that. Otherwise, -you are probably using TQString as an array of bytes, in which case use -TQByteArray or TQCString instead. -

TQString is not an array of bytes
-
-Code that uses TQString as an array of bytes should use TQByteArray -or a char[], then convert that to a TQString if needed. -

"string = 0"
-
-Assigning 0 to a TQString should be assigning the null string, -ie. string = TQString::null. -

System functions
-
-You may find yourself needing latin1() for passing to the operating system -or other libraries, and be tempted to use TQCString to save the conversion, -but you are better off using Unicode throughout, then when the operating -system supports Unicode, you'll be prepared. Some Unix operating systems -are now beginning to have basic Unicode support, and TQt will be tracking -these improvements as they become more widespread. -

Bugs removed
-
-toShort() returns 0 (and sets *ok to false) on error. -toUInt() now works for big valid unsigned integers. -insert() now works into the same string. -

NULL pointers
-
-When converting "const char*" usage to TQString in order to make your -application fully Unicode-aware, use TQString::null for the null value -where you would have used 0 with char pointers. -

TQString is not null terminated
-
-This means that inserting a 0-character -in the middle of the string does not change the length(). ie. -
-   TQString s = "fred";
-   s[1] = '\0';
-     // s.length() == 4
-     // s == "f\0ed"
-     // s.latin1() == "f"
-   s[1] = 'r';
-     // s == "fred"
-     // s.latin1() == "fred"
-
- -Especially look out for this type of code: -
-   TQString s(2);
-   s[0] = '?';
-   s[1] = 0;
-
- -This creates a string 2 characters long. -To find these problems while converting, you might like to -add Q_ASSERT(strlen(d->ascii)==d->len) inside -
 TQString::latin1()
- . -

TQString or Standard C++ string?
-
-

-The Standard C++ Library string is not Unicode. Nor is wstring defined -to be so (for the small number of platforms where it is defined at all). -This is the same mistake made over and over -in the history of C - only when non-8-bit characters are the norm -do programmers find them usable. Though it is possible to convert between -string and TQString, it is less efficient than using TQString throughout. -For example, when using: -

-    TQLabel::setText( const TQString& )
-
- -if you use string, like this: -
-    void myclass::dostuffwithtext( const string& str )
-    {
-        mylabel.setText( TQString(str.c_str()) );
-    }
-
- -that will create a (ASCII only) copy of str, stored in mylabel. -But this: -
-    void myclass::dostuffwithtext( const TQString& str )
-    {
-        mylabel.setText( str );
-    }
-
- -will make an implicitly shared reference to str in the TQLabel - no copying -at all. This function might be 10 nested function calls away from something -like this: -
-    void toplevelclass::initializationstuff()
-    {
-        doStuff( tr("Okay") );
-    }
-
- -At this point, in TQt 2.x, the tr() does a very fast dictionary lookup -through memory-mapped message files, returning some Unicode TQString for -the appropriate language (the default being to just make a TQString out -of the text, of course - you're not forced to use any of these -features), and that same memory mapped Unicode will be passed -though the system. All occurrences of the translation of "Okay" can -potentially be shared. -

-

TQApplication

-

In the function 

 TQApplication::setColorSpec()
- , -PrivateColor and TrueColor are obsolete. Use ManyColor instead. -

TQColor

-

-All colors -(color0, -color1, -black, -white, -darkGray, -gray, -lightGray, -red, -green, -blue, -cyan, -magenta, -yellow, -darkRed, -darkGreen, -darkBlue, -darkCyan, -darkMagenta, -and -darkYellow) -are in the TQt namespace. -In members of classes that inherit the TQt namespace-class (eg. TQWidget -subclasses), you can use the unqualified names as before, but in global -functions (eg. main()), you need to qualify them: TQt::red, TQt::white, etc. -See also the TQRgb section below. -

TQRgb

-

In TQRgb (a typedef of long), the order of the RGB channels has changed to -be in the more efficient order (for typical contemporary hardware). If your -code made assumptions about the order, you will get blue where you expect -red and vice versa (you'll not notice the problem if you use shades of -gray, green, or magenta). You should port your code to use the -creator function tqRgb(int r,int g,int b) and the -access functions tqRed(TQRgb), tqBlue(TQRgb), and tqGreen(TQRgb). -If you are using the alpha channel, it hasn't moved, but you should use -the functions tqRgba(int,int,int,int) and tqAlpha(TQRgb). Note also that -TQColor::pixel() does not return a TQRgb (it never did on all platforms, -but your code may have assumed so on your platform) - this may also produce -strange color results - use TQColor::rgb() if you want a TQRgb. -

TQDataStream

-

The TQDatastream serialization format of most TQt classes is changed -in TQt 2.x. Use 

 TQDataStream::setVersion( 1 )
- to get a -datastream object that can read and write TQt 1.x format data streams. -

If you want to write TQt 1.x format datastreams, note the following -compatibility issues: -

-

TQWidget

-

TQWidget::recreate()

-

-This function is now called reparent(). -

TQWidget::setAcceptFocus(bool)

-

-This function is removed. -Calls like TQWidget::setAcceptFocus(TRUE) should be replaced by -

 TQWidget::setFocusPolicy(StrongFocus)
- , and -calls like TQWidget::setAcceptFocus(FALSE) should be replaced by -
 TQWidget::setFocusPolicy(NoFocus)
- . -Additional policies are TabFocus and ClickFocus. -

TQWidget::paintEvent()

-

-paintEvent(0) is not permitted - subclasses need not check for -a null event, and might crash. -Never pass 0 as the argument to paintEvent(). You probably -just want repaint() or update() instead. -

-When processing a paintEvent, painting is only permitted within -the update region specified in the event. Any painting outside will be -clipped away. This shouldn't break any code (it was always like this -on MS-Windows) but makes many explicit calls to -TQPainter::setClipRegion() superfluous. Apart from the improved -consistency, the change is likely to reduce flicker and to make TQt -event slightly faster. -

TQIODevice

-

-The protected member TQIODevice::index is renamed to TQIODevice::ioIndex -to avoid warnings and to allow compilation with bad C libraries that -#define index to strchr. If you have made a subclass of TQIODevice, -check every occurrence of the string "index" in the implementation, since -a compiler will not always catch cases like 

(uint)index
- -that need to be changed. -

TQLabel

-

 TQLabel::setMargin()
-

-

-

 TQLabel::setMargin()
- and
 TQLabel::margin()
- -have been renamed to 
 TQLabel::setIndent()
- and -
 TQLabel::indent()
- , respectively. This was done to avoid -collision with TQFrame::setMargin(), which is now virtual. -

 TQLabel::setMovie()
-

-

-Previously, setting a movie on a label cleared the value of text(). -Now it doesn't. If you somehow used TQLabel::text() -to detect if a -movie was set, you might have trouble. This is unlikely. -

TQDialog

-

The semantics of the parent pointer changed for modeless dialogs: -In TQt-2.x, dialogs are always top level windows. The parent, however, -takes the ownership of the dialog, i.e. it will delete the dialog at -destruction if it has not been explicitly deleted -already. Furthermore, the window system will be able to tell that both -the dialog and the parent belong together. Some X11 window managers -will for instance provide a common taskbar entry in that case. -

-If the dialog belongs to a top level main window -of your application, pass this main window as parent to the dialog's -constructor. Old code (with 0 pointer) will still run. Old code that -included TQDialogs as child widgets will no longer work (it never really did). -If you think you might be doing this, put a breakpoint in -TQDialog::TQDialog() conditional on parent not being 0. -

TQStrList

-

Many methods that took a TQStrList can now instead take a TQStringList, -which is a real list of TQString values. -

To use TQStringList rather than TQStrList, change loops that look like this: -

-    TQStrList list = ...;
-    const char* s;
-    for ( s = list.first(); s; s = list.next() ) {
-        process(s);
-    }
-
- -to be like this: -
-    TQStringList list = ...;
-    TQStringList::ConstIterator i;
-    for ( i = list.begin(); i != list.end(); ++i ) {
-        process(*i);
-    }
-
- -

In general, the TQStrList functions are less efficient, building a temporary TQStringList. -

The following functions now use TQStringList rather than TQStrList -for return types/parameters. -

-

The following functions are added: -

-

The rarely used static function void -TQFont::listSubstitutions(TQStrList*) is replaced by TQStringList -TQFont::substitutions(). -

TQLayout

-

Calling resize(0,0) or resize(1,1) will no longer work magically. -Remove all such calls. The default size of top level widgets will be their -sizeHint(). -

The default implementation of TQWidget::sizeHint() will no longer -return just an invalid size; if the widget has a layout, it will return -the layout's preferred size. -

The special maximum MaximumHeight/Width is now TQWIDGETSIZE_MAX, -not TQCOORD_MAX. -

TQBoxLayout::addWidget() -now interprets the alignment parameter more aggressively. A -non-default alignment now indicates that the widget should not grow to -fill the available space, but should be sized according to sizeHint(). -If a widget is too small, set the alignment to 0. (Zero indicates no -alignment, and is the default.) -

The class TQGManager is removed. Subclasses of TQLayout need to be rewritten -to use the new, much simpler TQLayout API. -

For typical layouts, all use of -setMinimumSize() -and -setFixedSize() -can be removed. -activate() is no longer necessary. -

-You might like to look at the TQGrid, TQVBox, and TQHBox widgets - they offer -a simple way to build nested widget structures. -

TQListView

-

In TQt 1.x mouse events to the viewport where redirected to the -event handlers for the listview; in TQt 2.x, this functionality is -in TQScrollView where mouse (and other position-oriented) events are -redirected to viewportMousePressEvent() etc, which in turn translate -the event to the coordinate system of the contents and call -contentsMousePressEvent() etc, thus providing events in the most -convenient coordinate system. If you overrode TQListView::MouseButtonPress(), -TQListView::mouseDoubleClickEvent(), TQListView::mouseMoveEvent(), or -TQListView::mouseReleaseEvent() you must instead override -viewportMousePressEvent(), -viewportMouseDoubleClickEvent(), viewportMouseMoveEvent(), or -viewportMouseReleaseEvent() respectively. New code will usually override -contentsMousePressEvent() etc. -

The signal TQListView::selectionChanged(TQListViewItem *) can now be -emitted with a null pointer as parameter. Programs that use the -argument without checking for 0, may crash. -

TQMultiLineEdit

-

-The protected function -

 TQMultiLineEdit::textWidth(TQString*)
- -changed to -
 TQMultiLineEdit::textWidth(const TQString&)
- . -This is unlikely to be a problem, and you'll get a compile error -if you called it. -

TQClipboard

-

-

 TQClipboard::pixmap()
- now returns a TQPixmap, not a TQPixmap*. -The pixmap -will be null if no pixmap is on the -clipboard. TQClipboard now offers powerful MIME-based types on the -clipboard, just like drag-and-drop (in fact, you can reuse most of your -drag-and-drop code with clipboard operations). -

TQDropSite

-

-TQDropSite is obsolete. If you simply passed this, just remove -the inheritance of TQDropSite and call -setAcceptDrops(TRUE) in the class -constructor. -If you passed something other than this, -your code will not work. A common case is passing -the -viewport() of a TQListView, -in which case, -override the -contentsDragMoveEvent(), -etc. -functions rather than TQListView's dragMoveEvent() etc. For other -cases, you will need to use an event filter to act on the drag/drop events -of another widget (as is the usual way to intercept foreign events). -

TQScrollView

-

The parameters in the signal -contentsMoving(int,int) -are now positive rather than negative values, coinciding with -setContentsPos(). Search for -connections you make to this signal, and either change the slot they are -connected to such that it also expects positive rather than negative -values, or introduce an intermediate slot and signal that negates them. -

If you used drag and drop with TQScrollView, you may experience the problem -described for TQDropSite. -

TQTextStream

-

-

 operator<<(TQTextStream&, TQChar&)
- does not skip whitespace. -
 operator<<(TQTextStream&, char&)
- does, -as was the case with TQt 1.x. This is for backward compatibility. -

TQUriDrag

-

The class TQUrlDrag is renamed to TQUriDrag, and the API has been -broadened to include additional conversion routines, including -conversions to Unicode filenames (see the class documentation -for details). Note that in TQt 1.x -the TQUrlDrag class used the non-standard MIME type "url/url", -while TQUriDrag uses the standardized "text/uri-list" type. Other -identifiers affected by the Url to Uri change are -TQUrlDrag::setUrls() and TQUrlDrag::urlToLocalFile(). -

TQPainter

-

The GrayText painter flag has been removed. Use -setPen( palette().disabled().foreground() ) -instead. -

The RasterOp enum -(CopyROP, -OrROP, -XorROP, -NotAndROP, -EraseROP, -NotCopyROP, -NotOrROP, -NotXorROP, -AndROP, NotEraseROP, -NotROP, -ClearROP, -SetROP, -NopROP, -AndNotROP, -OrNotROP, -NandROP, -NorROP, LastROP) -is now part of the TQt namespace class, so if you -use it outside a member function, you'll need to prefix with TQt::. -

TQPicture

-

The binary storage format of TQPicture is changed, but the TQt 2.x -TQPicture class can both read and write TQt 1.x format TQPictures. No -special handling is required for reading; TQPicture will automatically -detect the version number. In order to write a TQt 1.x format TQPicture, -set the formatVersion parameter to 1 in the TQPicture constructor. -

For writing TQt 1.x format TQPictures, the compatibility issues of TQDataStream applies. -

It is safe to try to read a TQPicture file generated with TQt 2.x -(without formatVersion set to 1) with a program compiled with TQt -1.x. The program will not crash, it will just issue the warning -"TQPicture::play: Incompatible version 2.x" and refuse to load the -picture. -

TQPoint, TQPointArray, TQSize and TQRect

-

The basic coordinate datatype in these classes, TQCOORD, is now 32 -bit (int) instead of a 16 bit (short). The const values TQCOORD_MIN and -TQCOORD_MAX have changed accordingly. -

TQPointArray is now actually, not only seemingly, a TQArray of TQPoint -objects. The semi-internal workaround classes TQPointData and TQPointVal -are removed since they are no longer needed; TQPoint is used directly -instead. The function 

 TQPointArray::shortPoints()
- -provides the point array converted to short (16bit) coordinates for -use with external functions that demand that format. -

TQImage

-

TQImage uses TQRgb for the colors - see the changes to that. -

TQPixmap

-

 TQPixmap::convertToImage()
- with bitmaps now guarantees that color0 pixels -become color(0) in the resulting TQImage. If you worked around the lack of -this, you may be able to simplify your code. If you made assumptions -about the previous undefined behavior, the symptom will be inverted -bitmaps (eg. "inside-out" masks). -

-

 TQPixmap::optimize(TRUE)
- -is replaced by -
 TQPixmap::setOptimization(TQPixmap::NormalOptim)
- -or -
 TQPixmap::setOptimization(TQPixmap::BestOptim)
- -- see the documentation -to choose which is best for your application. NormalOptim is most like -the TQt 1.x "TRUE" optimization. -

TQMenuData / TQPopupMenu

-

In TQt 1.x, new menu items were assigned either an application-wide -unique identifier or an identifier equal to the index of the item, depending on the -insertItem(...) function used. -In TQt 2.x this confusing -situation has been cleaned up: generated identifiers are always -unique across the entire application. -

If your code depends on generated ids -being equal to the item's index, a quick fix is to use -

 TQMenuData::indexOf(int id)
- -in the handling function instead. You may alternatively pass -
 TQMenuData::count()
- -as identifier when you insert the items. -

Furthermore, TQPopupMenus can (and should!) be created with a parent -widget now, for example the main window that is used to display the -popup. This way, the popup will automatically be destroyed together -with its main window. Otherwise you'll have to take care of the -ownership manually. -

TQPopupMenus are also reusable in 2.x. They may occur in different -locations within one menu structure or be used as both a menubar -drop-down and as a context popup-menu. This should make it possible to -significantly simplify many applications. -

Last but not least, TQPopupMenu no longer inherits TQTableView. Instead, -it directly inherits TQFrame. -

TQValidator (TQLineEdit, TQComboBox, TQSpinBox)

-

 TQValidator::validate(...)
- -and -
 TQValidator::fixup( TQString & )
- -are now const -functions. If your subclass reimplements validate() as a -non-const function, -you will get a compile error (validate was pure virtual). -

In TQLineEdit, TQComboBox, and TQSpinBox, -setValidator(...) now takes a const pointer to a TQValidator, and -validator() returns a const pointer. This change highlights the fact -that the widgets do not take the ownership of the validator (a validator is -a TQObject on its own, with its own parent - you can easily set the same validator -object on many different widgets), so changing the state of -such an object or deleting it is very likely a bug. -

TQFile, TQFileInfo, TQDir

-

File and directory names are now always Unicode strings (ie. TQString). If you used TQString -in the past for the simplicity it offers, you'll probably have little consequence. However, -if you pass filenames to system functions rather than using TQt functions (eg. if you use the -Unix unlink() function rather than TQFile::remove(), your code will probably -only work for Latin1 locales (eg. Western Europe, the U.S.). To ensure your code will support -filenames in other locales, either use the TQt functions, or convert the filenames via -

 TQFile::encodeFilename()
- and 
 TQFile::decodeFilename()
- - but do it -just as you call the system function - code that mixes encoded and unencoded filenames -is very error prone. See the comments in TQString, such as regarding TQT_NO_ASCII_CAST that -can help find potential problems. -

TQFontMetrics

-

boundingRect(char) is replaced by -boundingRect(TQChar), but since -char auto-converts to TQChar, you're not likely to run into problems -with this. -

TQWindow

-

This class (which was just TQWidget under a different name) has been -removed. If you used it, do a global search-and-replace of the word -"TQWindow" with "TQWidget". -

TQEvent

-

The global #define macros in ntqevent.h have been replaced by an -enum in TQEvent. Use e.g. TQEvent::Paint instead of Event_Paint. Same -for all of: -Event_None, -Event_Timer, -Event_MouseButtonPress, -Event_MouseButtonRelease, -Event_MouseButtonDblClick, -Event_MouseMove, -Event_KeyPress, -Event_KeyRelease, -Event_FocusIn, -Event_FocusOut, -Event_Enter, -Event_Leave, -Event_Paint, -Event_Move, -Event_Resize, -Event_Create, -Event_Destroy, -Event_Show, -Event_Hide, -Event_Close, -Event_Quit, -Event_Accel, -Event_Clipboard, -Event_SockAct, -Event_DragEnter, -Event_DragMove, -Event_DragLeave, -Event_Drop, -Event_DragResponse, -Event_ChildInserted, -Event_ChildRemoved, -Event_LayoutHint, -Event_ActivateControl, -Event_DeactivateControl, -and -Event_User. -

The Q_*_EVENT macros in ntqevent.h have been deleted. Use an -explicit cast instead. The macros were: -Q_TIMER_EVENT, -Q_MOUSE_EVENT, -Q_KEY_EVENT, -Q_FOCUS_EVENT, -Q_PAINT_EVENT, -Q_MOVE_EVENT, -Q_RESIZE_EVENT, -Q_CLOSE_EVENT, -Q_SHOW_EVENT, -Q_HIDE_EVENT, -and -Q_CUSTOM_EVENT. -

TQChildEvents are now sent for all TQObjects, not just TQWidgets. -You may need to add extra checking if you use a TQChildEvent without -much testing of its values. -

All the removed functions

-

All these functions have been removed in -TQt 2.x. Most are simply cases where "const char*" has changed to -"const TQString&", or when an enumeration type has moved into the TQt:: -namespace (which, technically, is a new name, but your code will -compile just the same anyway). This list is provided for completeness. -

- -

- -
Copyright © 2007 -TrolltechTrademarks -
TQt 3.3.8
-
- -- cgit v1.2.1