diff options
Diffstat (limited to 'doc/html/porting2.html')
| -rw-r--r-- | doc/html/porting2.html | 200 |
1 files changed, 100 insertions, 100 deletions
diff --git a/doc/html/porting2.html b/doc/html/porting2.html index 723a4e0a0..0276d068b 100644 --- a/doc/html/porting2.html +++ b/doc/html/porting2.html @@ -107,7 +107,7 @@ that is the TQt Developer Community! <li><b><a href="#TQMultiLineEdit">TQMultiLineEdit</a></b> <li><b><a href="#TQPainter">TQPainter</a></b> <li><b><a href="#TQPicture">TQPicture</a></b> -<li><b><a href="#TQPoint">TQPoint, <a href="qpointarray.html">TQPointArray</a>, <a href="qsize.html">TQSize</a> and <a href="qrect.html">TQRect</a></a></b> +<li><b><a href="#TQPoint">TQPoint, <a href="ntqpointarray.html">TQPointArray</a>, <a href="ntqsize.html">TQSize</a> and <a href="ntqrect.html">TQRect</a></a></b> <li><b><a href="#TQPixmap">TQPixmap</a></b> <li><b><a href="#TQRgb">TQRgb</a></b> <li><b><a href="#TQScrollView">TQScrollView</a></b> @@ -127,9 +127,9 @@ that is the TQt Developer Community! <p> <p> TQt 2.x is namespace-clean, unlike 1.x. TQt now uses very few global identifiers. Identifiers like <code>red, blue, LeftButton, AlignRight, Key_Up, Key_Down, NoBrush</code> etc. are now part of a -special class <code>TQt</code> (defined in qnamespace.h), +special class <code>TQt</code> (defined in ntqnamespace.h), which is inherited by -most TQt classes. Member functions of classes that inherit from <a href="qwidget.html">TQWidget</a>, +most TQt classes. Member functions of classes that inherit from <a href="ntqwidget.html">TQWidget</a>, etc. are totally unaffected, but code that is <em>not</em> in functions of classes inherited from <code>TQt</code>, you must qualify these identifiers like this: <code>TQt::red, @@ -186,7 +186,7 @@ of your functions accordingly. <li><pre> TQValidator::fixup(TQString &)</pre> -<li><pre> TQSlider::paintSlider(TQPainter *, const <a href="qrect.html">TQRect</a> &)</pre> +<li><pre> TQSlider::paintSlider(TQPainter *, const <a href="ntqrect.html">TQRect</a> &)</pre> </ul> <p> This is one class of changes that are @@ -202,10 +202,10 @@ function that is not in a subclass of <a href="qlistviewitem.html">TQListViewIte <p> <h3><a name="Collection">Collection classes</a></h3> <p> <p> The <a href="collection.html#collection-classes">collection classes</a> include generic classes such as TQGDict, TQGList, and -the subclasses such as <a href="qdict.html">TQDict</a> and TQList. +the subclasses such as <a href="ntqdict.html">TQDict</a> and TQList. <p> <p> The macro-based TQt collection classes are obsolete; use the -template-based classes instead. Simply remove includes of qgeneric.h and -replace e.g. Q_DECLARE(<a href="qcache.html">TQCache</a>,TQPixmap) with TQCache<TQPixmap>. +template-based classes instead. Simply remove includes of ntqgeneric.h and +replace e.g. Q_DECLARE(<a href="ntqcache.html">TQCache</a>,TQPixmap) with TQCache<TQPixmap>. <p> <p> 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. @@ -217,9 +217,9 @@ is not set (i.e. if the QT_NO_CHECK flag is defined). <p> <p>The debug() function now outputs nothing if TQt was compiled with the QT_NO_DEBUG macro defined. <p> <h3><a name="TQString">TQString</a></h3> -<p> <a href="qstring.html">TQString</a> has undergone major changes internally, and although it is highly +<p> <a href="ntqstring.html">TQString</a> 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 <a href="qcstring.html">TQCString</a> in TQt 2.x, though if +The TQt 1.x TQString class has been renamed to <a href="ntqcstring.html">TQCString</a> 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&. <p> <p> @@ -237,7 +237,7 @@ might indicate that the true nature of the data you are dealing with is uncertain. If the data is NUL-terminated 8-bit data, use TQCString; if it is unterminated (ie. contains NULs) 8-bit data, use TQByteArray; if it is text, -use <a href="qstring.html">TQString</a>. +use <a href="ntqstring.html">TQString</a>. </p> <li> Put a breakpoint in <pre> TQString::latin1()</pre> @@ -268,7 +268,7 @@ and ideally you'll only need latin1() or implicit conversion when interfacing to facilities that do not have Unicode support. <p> <dt><b>Automatic-expanding</b></dt> <dd> -A big advantage of the new <a href="qstring.html">TQString</a> is that it automatically expands +A big advantage of the new <a href="ntqstring.html">TQString</a> is that it automatically expands when you write to an indexed position. <p> <dt><b>TQChar and <a href="qcharref.html">TQCharRef</a></b></dt> <dd> @@ -282,11 +282,11 @@ 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). <p> <dt><b>Use TQString</b></dt> <dd> -Try to always use TQString. If you <em>must</em>, use <a href="qcstring.html">TQCString</a> which is the +Try to always use TQString. If you <em>must</em>, use <a href="ntqcstring.html">TQCString</a> which is the old implementation from TQt 1.x. <p> <dt><b>Unicode vs. ASCII</b></dt> <dd> -Every conversion to and from ASCII is wasted time, so try to use <a href="qstring.html">TQString</a> +Every conversion to and from ASCII is wasted time, so try to use <a href="ntqstring.html">TQString</a> as much as possible rather than const char*. This also ensures you have full 16-bit support. <p> <dt><b>Convertion to ASCII</b></dt> @@ -309,11 +309,11 @@ use_sub_string( my_string.mid(index) ) <dd> 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 <a href="qstring.html#left">TQString::left</a>(int) or <a href="qstring.html#fromLatin1">TQString::fromLatin1</a>( const char*, +'\0' terminator. Use <a href="ntqstring.html#left">TQString::left</a>(int) or <a href="ntqstring.html#fromLatin1">TQString::fromLatin1</a>( const char*, int ) -- in both cases the int parameter signifies the number of characters. <p> <dt><b>TQString(int) is private</b></dt> <dd> -The <a href="qstring.html">TQString</a> constructor taking an integer is now private. This function +The <a href="ntqstring.html">TQString</a> 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(). @@ -328,9 +328,9 @@ 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 <a href="qstring.html#TQString-null">TQString::null</a>, though note that +syntax is to use <a href="ntqstring.html#TQString-null">TQString::null</a>, though note that the default constructor, TQString(), creates a null string too. -Assignment of 0 to a <a href="qstring.html">TQString</a> is ambiguous - assign +Assignment of 0 to a <a href="ntqstring.html">TQString</a> 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 @@ -356,28 +356,28 @@ summary of how much your application is doing Unicode and ASCII back-and-forth conversions. <p> <dt><b>TQString::detach() is obsolete and removed</b></dt> <dd> -Since <a href="qstring.html">TQString</a> is now always shared, this function does nothing. +Since <a href="ntqstring.html">TQString</a> is now always shared, this function does nothing. Remove calls to TQString::detach(). <p> <dt><b>TQString::resize(int size) is obsolete and removed</b></dt> <dd> Code using this to truncate a string should use -<a href="qstring.html#truncate">truncate(size-1)</a>. +<a href="ntqstring.html#truncate">truncate(size-1)</a>. Code using qstr.resize(0) should use qstr = TQString::null. Code calling resize(n) prior to using -<a href="qstring.html#operator[]">operator[]</a> up to n just remove +<a href="ntqstring.html#operator[]">operator[]</a> up to n just remove the resize(n) completely. <p> <dt><b>TQString::size() is obsolete and removed</b></dt> <dd> Calls to this function must be replaced by -<a href="qstring.html#length">length()</a>+1. +<a href="ntqstring.html#length">length()</a>+1. <p> <dt><b>TQString::setStr(const char*) is removed</b></dt> <dd>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 -<a href="qbytearray.html">TQByteArray</a> or <a href="qcstring.html">TQCString</a> instead. +<a href="qbytearray.html">TQByteArray</a> or <a href="ntqcstring.html">TQCString</a> instead. <p> <dt><b>TQString is not an array of bytes</b></dt> <dd> -Code that uses <a href="qstring.html">TQString</a> as an array of bytes should use TQByteArray +Code that uses <a href="ntqstring.html">TQString</a> as an array of bytes should use TQByteArray or a char[], <em>then</em> convert that to a TQString if needed. <p> <dt><b>"string = 0"</b></dt> <dd> @@ -406,26 +406,26 @@ where you would have used 0 with char pointers. This means that inserting a 0-character in the middle of the string does <em>not</em> change the length(). ie. <pre> - <a href="qstring.html">TQString</a> s = "fred"; + <a href="ntqstring.html">TQString</a> s = "fred"; s[1] = '\0'; - // s.<a href="qstring.html#length">length</a>() == 4 + // s.<a href="ntqstring.html#length">length</a>() == 4 // s == "f\0ed" - // s.<a href="qstring.html#latin1">latin1</a>() == "f" + // s.<a href="ntqstring.html#latin1">latin1</a>() == "f" s[1] = 'r'; // s == "fred" - // s.<a href="qstring.html#latin1">latin1</a>() == "fred" + // s.<a href="ntqstring.html#latin1">latin1</a>() == "fred" </pre> Especially look out for this type of code: <pre> - <a href="qstring.html">TQString</a> s(2); + <a href="ntqstring.html">TQString</a> s(2); s[0] = '?'; s[1] = 0; </pre> This creates a string 2 characters long. To find these problems while converting, you might like to -add <a href="qapplication.html#Q_ASSERT">Q_ASSERT</a>(strlen(d->ascii)==d->len) inside +add <a href="ntqapplication.html#Q_ASSERT">Q_ASSERT</a>(strlen(d->ascii)==d->len) inside <pre> TQString::latin1()</pre> . <p> <dt><b>TQString or Standard C++ string?</b></dt> @@ -436,10 +436,10 @@ 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 <em>the norm</em> do programmers find them usable. Though it is possible to convert between -string and <a href="qstring.html">TQString</a>, it is less efficient than using TQString throughout. +string and <a href="ntqstring.html">TQString</a>, it is less efficient than using TQString throughout. For example, when using: <pre> - TQLabel::<a href="qlabel.html#setText">setText</a>( const <a href="qstring.html">TQString</a>& ) + TQLabel::<a href="ntqlabel.html#setText">setText</a>( const <a href="ntqstring.html">TQString</a>& ) </pre> if you use string, like this: @@ -453,13 +453,13 @@ if you use string, like this: that will create a (ASCII only) copy of str, stored in mylabel. But this: <pre> - void myclass::dostuffwithtext( const <a href="qstring.html">TQString</a>& str ) + void myclass::dostuffwithtext( const <a href="ntqstring.html">TQString</a>& str ) { mylabel.setText( str ); } </pre> -will make an <a href="shclass.html#implicitly-shared">implicitly shared</a> reference to str in the <a href="qlabel.html">TQLabel</a> - no copying +will make an <a href="shclass.html#implicitly-shared">implicitly shared</a> reference to str in the <a href="ntqlabel.html">TQLabel</a> - no copying at all. This function might be 10 nested function calls away from something like this: <pre> @@ -470,7 +470,7 @@ like this: </pre> At this point, in TQt 2.x, the tr() does a very fast dictionary lookup -through memory-mapped message files, returning some Unicode <a href="qstring.html">TQString</a> for +through memory-mapped message files, returning some Unicode <a href="ntqstring.html">TQString</a> for the appropriate language (the default being to just make a TQString out of the text, of course - you're not <em>forced</em> to use any of these features), and that <em>same</em> memory mapped Unicode will be passed @@ -505,7 +505,7 @@ darkMagenta, and darkYellow) are in the TQt namespace. -In members of classes that inherit the TQt namespace-class (eg. <a href="qwidget.html">TQWidget</a> +In members of classes that inherit the TQt namespace-class (eg. <a href="ntqwidget.html">TQWidget</a> 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 <a href="#TQRgb">TQRgb</a> section below. @@ -515,13 +515,13 @@ 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 <a href="qcolor.html#qRgb">qRgb</a>(int r,int g,int b) and the -access functions <a href="qcolor.html#qRed">qRed</a>(TQRgb), <a href="qcolor.html#qBlue">qBlue</a>(TQRgb), and <a href="qcolor.html#qGreen">qGreen</a>(TQRgb). +creator function <a href="ntqcolor.html#qRgb">qRgb</a>(int r,int g,int b) and the +access functions <a href="ntqcolor.html#qRed">qRed</a>(TQRgb), <a href="ntqcolor.html#qBlue">qBlue</a>(TQRgb), and <a href="ntqcolor.html#qGreen">qGreen</a>(TQRgb). If you are using the alpha channel, it hasn't moved, but you should use -the functions <a href="qcolor.html#qRgba">qRgba</a>(int,int,int,int) and <a href="qcolor.html#qAlpha">qAlpha</a>(TQRgb). Note also that -<a href="qcolor.html#pixel">TQColor::pixel</a>() does <i>not</i> return a TQRgb (it never did on all platforms, +the functions <a href="ntqcolor.html#qRgba">qRgba</a>(int,int,int,int) and <a href="ntqcolor.html#qAlpha">qAlpha</a>(TQRgb). Note also that +<a href="ntqcolor.html#pixel">TQColor::pixel</a>() does <i>not</i> 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 <a href="qcolor.html#rgb">TQColor::rgb</a>() if you want a TQRgb. +strange color results - use <a href="ntqcolor.html#rgb">TQColor::rgb</a>() if you want a TQRgb. <p> <h3><a name="TQDataStream">TQDataStream</a></h3> <p> <p>The TQDatastream serialization format of most TQt classes is changed in TQt 2.x. Use <pre> TQDataStream::setVersion( 1 )</pre> @@ -532,7 +532,7 @@ compatibility issues: <ul> <li>TQString: TQt 1.x has no Unicode support, so strings will be serialized by writing the classic C string returned by <pre> - TQString::<a href="qstring.html#latin1">latin1</a>().</pre> + TQString::<a href="ntqstring.html#latin1">latin1</a>().</pre> <li><a href="#TQPoint">TQPoint & al.</a>: Coordinates will be truncated to the TQt 1.x 16 bit format. @@ -540,7 +540,7 @@ truncated to the TQt 1.x 16 bit format. <p> <h3><a name="TQWidget">TQWidget</a></h3> <p> <h4>TQWidget::recreate()</h4> <p> -This function is now called <a href="qwidget.html#reparent">reparent()</a>. +This function is now called <a href="ntqwidget.html#reparent">reparent()</a>. <p> <h4>TQWidget::setAcceptFocus(bool)</h4> <p> This function is removed. @@ -562,14 +562,14 @@ 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 -<a href="qpainter.html#setClipRegion">TQPainter::setClipRegion</a>() superfluous. Apart from the improved +<a href="ntqpainter.html#setClipRegion">TQPainter::setClipRegion</a>() superfluous. Apart from the improved consistency, the change is likely to reduce flicker and to make TQt event slightly faster. <p> <h3><a name="TQIODevice">TQIODevice</a></h3> <p> 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 <a href="qiodevice.html">TQIODevice</a>, +#define index to strchr. If you have made a subclass of <a href="ntqiodevice.html">TQIODevice</a>, check every occurrence of the string "index" in the implementation, since a compiler will not always catch cases like <pre>(uint)index</pre> @@ -585,7 +585,7 @@ have been renamed to <pre> TQLabel::setIndent()</pre> and <pre> TQLabel::indent()</pre> , respectively. This was done to avoid -collision with <a href="qframe.html#setMargin">TQFrame::setMargin</a>(), which is now virtual. +collision with <a href="ntqframe.html#setMargin">TQFrame::setMargin</a>(), which is now virtual. <p> <h4><pre> TQLabel::setMovie()</pre> </h4> <p> @@ -607,24 +607,24 @@ 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 -<a href="qdialog.html#TQDialog">TQDialog::TQDialog</a>() conditional on parent not being 0. +<a href="ntqdialog.html#TQDialog">TQDialog::TQDialog</a>() conditional on parent not being 0. <p> <h3><a name="TQStrList">TQStrList</a></h3> -<p> Many methods that took a <a href="qstrlist.html">TQStrList</a> can now instead take a <a href="qstringlist.html">TQStringList</a>, -which is a real list of <a href="qstring.html">TQString</a> values. +<p> Many methods that took a <a href="ntqstrlist.html">TQStrList</a> can now instead take a <a href="ntqstringlist.html">TQStringList</a>, +which is a real list of <a href="ntqstring.html">TQString</a> values. <p> To use TQStringList rather than TQStrList, change loops that look like this: <pre> - <a href="qstrlist.html">TQStrList</a> list = ...; + <a href="ntqstrlist.html">TQStrList</a> list = ...; const char* s; - for ( s = list.<a href="qptrlist.html#first">first</a>(); s; s = list.<a href="qptrlist.html#next">next</a>() ) { + for ( s = list.<a href="ntqptrlist.html#first">first</a>(); s; s = list.<a href="ntqptrlist.html#next">next</a>() ) { process(s); } </pre> to be like this: <pre> - <a href="qstringlist.html">TQStringList</a> list = ...; + <a href="ntqstringlist.html">TQStringList</a> list = ...; TQStringList::ConstIterator i; - for ( i = list.<a href="qvaluelist.html#begin">begin</a>(); i != list.<a href="qvaluelist.html#end">end</a>(); ++i ) { + for ( i = list.<a href="ntqvaluelist.html#begin">begin</a>(); i != list.<a href="ntqvaluelist.html#end">end</a>(); ++i ) { process(*i); } </pre> @@ -633,14 +633,14 @@ to be like this: <p> The following functions now use TQStringList rather than TQStrList for return types/parameters. <p> <ul> -<li><tt>void <a href="qfiledialog.html#setFilters">TQFileDialog::setFilters</a>(const <a href="qstrlist.html">TQStrList</a>&)</tt> -becomes <tt>void TQFileDialog::setFilters(const <a href="qstringlist.html">TQStringList</a>&)</tt> -<li><tt>TQStrList <a href="qfiledialog.html#getOpenFileNames">TQFileDialog::getOpenFileNames</a>(...)</tt> +<li><tt>void <a href="ntqfiledialog.html#setFilters">TQFileDialog::setFilters</a>(const <a href="ntqstrlist.html">TQStrList</a>&)</tt> +becomes <tt>void TQFileDialog::setFilters(const <a href="ntqstringlist.html">TQStringList</a>&)</tt> +<li><tt>TQStrList <a href="ntqfiledialog.html#getOpenFileNames">TQFileDialog::getOpenFileNames</a>(...)</tt> becomes <tt>TQStringList TQFileDialog::getOpenFileNames(...)</tt> <li><tt>bool TQUrlDrag::decodeLocalFiles(<a href="qmimesource.html">TQMimeSource</a>*, TQStrList&)</tt> becomes <tt>bool <a href="quridrag.html#decodeLocalFiles">TQUriDrag::decodeLocalFiles</a>(TQMimeSource*, TQStringList&)</tt> <li><tt>const TQStrList *TQDir::entryList(...) const</tt> -becomes <tt>TQStringList <a href="qdir.html#entryList">TQDir::entryList</a>(...) const</tt> +becomes <tt>TQStringList <a href="ntqdir.html#entryList">TQDir::entryList</a>(...) const</tt> (note that the return type is no longer a pointer). You may also choose to use encodedEntryList(). </ul> @@ -650,13 +650,13 @@ choose to use encodedEntryList(). <li><tt>TQListBox::insertStringList(const TQStringList &,int index=-1)</tt> </ul> <p> The rarely used static function <tt>void -TQFont::listSubstitutions(<a href="qstrlist.html">TQStrList</a>*)</tt> is replaced by <tt>TQStringList -<a href="qfont.html#substitutions">TQFont::substitutions</a>()</tt>. +TQFont::listSubstitutions(<a href="ntqstrlist.html">TQStrList</a>*)</tt> is replaced by <tt>TQStringList +<a href="ntqfont.html#substitutions">TQFont::substitutions</a>()</tt>. <p> <h3><a name="TQLayout">TQLayout</a></h3> <p> <p> 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 -<a href="qwidget.html#sizeHint">sizeHint()</a>. -<p> <p> The default implementation of <a href="qwidget.html#sizeHint">TQWidget::sizeHint</a>() will no longer +<a href="ntqwidget.html#sizeHint">sizeHint()</a>. +<p> <p> The default implementation of <a href="ntqwidget.html#sizeHint">TQWidget::sizeHint</a>() will no longer return just an invalid size; if the widget has a layout, it will return the layout's preferred size. <p> <p> The special maximum MaximumHeight/Width is now TQWIDGETSIZE_MAX, @@ -667,32 +667,32 @@ 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.) -<p> <p> The class TQGManager is removed. Subclasses of <a href="qlayout.html">TQLayout</a> need to be rewritten -to use the new, much simpler <a href="qlayout.html">TQLayout API</a>. +<p> <p> The class TQGManager is removed. Subclasses of <a href="ntqlayout.html">TQLayout</a> need to be rewritten +to use the new, much simpler <a href="ntqlayout.html">TQLayout API</a>. <p> <p> For typical layouts, all use of -<a href="qwidget.html#setMinimumSize">setMinimumSize()</a> +<a href="ntqwidget.html#setMinimumSize">setMinimumSize()</a> and -<a href="qwidget.html#setFixedSize">setFixedSize()</a> +<a href="ntqwidget.html#setFixedSize">setFixedSize()</a> can be removed. -<a href="qlayout.html#activate">activate()</a> is no longer necessary. +<a href="ntqlayout.html#activate">activate()</a> is no longer necessary. <p> <p> -You might like to look at the <a href="qgrid.html">TQGrid</a>, <a href="qvbox.html">TQVBox</a>, and <a href="qhbox.html">TQHBox</a> widgets - they offer +You might like to look at the <a href="ntqgrid.html">TQGrid</a>, <a href="ntqvbox.html">TQVBox</a>, and <a href="ntqhbox.html">TQHBox</a> widgets - they offer a simple way to build nested widget structures. <p> <h3><a name="TQListView">TQListView</a></h3> <p> <p>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 <a href="qscrollview.html">TQScrollView</a> where mouse (and other position-oriented) events are +in <a href="ntqscrollview.html">TQScrollView</a> 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(), -<a href="qwidget.html#mouseDoubleClickEvent">TQListView::mouseDoubleClickEvent</a>(), <a href="qwidget.html#mouseMoveEvent">TQListView::mouseMoveEvent</a>(), or -<a href="qwidget.html#mouseReleaseEvent">TQListView::mouseReleaseEvent</a>() you must instead override +<a href="ntqwidget.html#mouseDoubleClickEvent">TQListView::mouseDoubleClickEvent</a>(), <a href="ntqwidget.html#mouseMoveEvent">TQListView::mouseMoveEvent</a>(), or +<a href="ntqwidget.html#mouseReleaseEvent">TQListView::mouseReleaseEvent</a>() you must instead override viewportMousePressEvent(), viewportMouseDoubleClickEvent(), viewportMouseMoveEvent(), or viewportMouseReleaseEvent() respectively. New code will usually override contentsMousePressEvent() etc. -<p> <p>The signal <a href="qlistview.html#selectionChanged">TQListView::selectionChanged</a>(<a href="qlistviewitem.html">TQListViewItem</a> *) can now be +<p> <p>The signal <a href="ntqlistview.html#selectionChanged">TQListView::selectionChanged</a>(<a href="qlistviewitem.html">TQListViewItem</a> *) can now be emitted with a null pointer as parameter. Programs that use the argument without checking for 0, may crash. <p> <h3><a name="TQMultiLineEdit">TQMultiLineEdit</a></h3> @@ -701,45 +701,45 @@ The protected function <pre> TQMultiLineEdit::textWidth(TQString*)</pre> changed to -<pre> TQMultiLineEdit::textWidth(const <a href="qstring.html">TQString</a>&)</pre> +<pre> TQMultiLineEdit::textWidth(const <a href="ntqstring.html">TQString</a>&)</pre> . This is unlikely to be a problem, and you'll get a compile error if you called it. <p> <h3><a name="TQClipboard">TQClipboard</a></h3> <p> <p> <pre> TQClipboard::pixmap()</pre> - now returns a <a href="qpixmap.html">TQPixmap</a>, not a TQPixmap*. + now returns a <a href="ntqpixmap.html">TQPixmap</a>, not a TQPixmap*. The pixmap -will be <a href="qpixmap.html#isNull">null</a> if no pixmap is on the -clipboard. <a href="qclipboard.html">TQClipboard</a> now offers powerful MIME-based types on the +will be <a href="ntqpixmap.html#isNull">null</a> if no pixmap is on the +clipboard. <a href="ntqclipboard.html">TQClipboard</a> 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). <p> <h3><a name="TQDropSite">TQDropSite</a></h3> <p> <P> TQDropSite is obsolete. If you simply passed <tt>this</tt>, just remove the inheritance of TQDropSite and call -<a href="qwidget.html#setAcceptDrops">setAcceptDrops(TRUE)</a> in the class +<a href="ntqwidget.html#setAcceptDrops">setAcceptDrops(TRUE)</a> in the class constructor. If you passed something other than <tt>this</tt>, your code will not work. A common case is passing the -<a href="qscrollview.html#viewport">viewport()</a> of a <a href="qlistview.html">TQListView</a>, +<a href="ntqscrollview.html#viewport">viewport()</a> of a <a href="ntqlistview.html">TQListView</a>, in which case, override the -<a href="qscrollview.html#contentsDragMoveEvent">contentsDragMoveEvent()</a>, +<a href="ntqscrollview.html#contentsDragMoveEvent">contentsDragMoveEvent()</a>, 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). <p> <h3><a name="TQScrollView">TQScrollView</a></h3> <p> The parameters in the signal -<a href="qscrollview.html#contentsMoving">contentsMoving(int,int)</a> +<a href="ntqscrollview.html#contentsMoving">contentsMoving(int,int)</a> are now positive rather than negative values, coinciding with -<a href="qscrollview.html#setContentsPos">setContentsPos()</a>. Search for +<a href="ntqscrollview.html#setContentsPos">setContentsPos()</a>. 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. -<p> If you used drag and drop with <a href="qscrollview.html">TQScrollView</a>, you may experience the problem +<p> If you used drag and drop with <a href="ntqscrollview.html">TQScrollView</a>, you may experience the problem described for <a href="#TQDropSite">TQDropSite</a>. <p> <h3><a name="TQTextStream">TQTextStream</a></h3> <p> <p> @@ -759,7 +759,7 @@ identifiers affected by the Url to Uri change are TQUrlDrag::setUrls() and TQUrlDrag::urlToLocalFile(). <p> <h3><a name="TQPainter">TQPainter</a></h3> <p> <p> The GrayText painter flag has been removed. Use -<a href="qpainter.html#setPen">setPen( palette().disabled().foreground() )</a> +<a href="ntqpainter.html#setPen">setPen( palette().disabled().foreground() )</a> instead. <p> <p> The RasterOp enum (CopyROP, @@ -782,7 +782,7 @@ 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::. <p> <h3><a name="TQPicture">TQPicture</a></h3> -<p> <p>The binary storage format of <a href="qpicture.html">TQPicture</a> is changed, but the TQt 2.x +<p> <p>The binary storage format of <a href="ntqpicture.html">TQPicture</a> 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, @@ -794,11 +794,11 @@ href="#TQDataStream">TQDataStream</a> applies. 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. -<p> <h3><a name="TQPoint">TQPoint, <a href="qpointarray.html">TQPointArray</a>, <a href="qsize.html">TQSize</a> and <a href="qrect.html">TQRect</a></a></h3> +<p> <h3><a name="TQPoint">TQPoint, <a href="ntqpointarray.html">TQPointArray</a>, <a href="ntqsize.html">TQSize</a> and <a href="ntqrect.html">TQRect</a></a></h3> <p> <p>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. -<p> <p>TQPointArray is now actually, not only seemingly, a TQArray of <a href="qpoint.html">TQPoint</a> +<p> <p>TQPointArray is now actually, not only seemingly, a TQArray of <a href="ntqpoint.html">TQPoint</a> objects. The semi-internal workaround classes TQPointData and TQPointVal are removed since they are no longer needed; TQPoint is used directly instead. The function <pre> TQPointArray::shortPoints()</pre> @@ -806,7 +806,7 @@ instead. The function <pre> TQPointArray::shortPoints()</pre> provides the point array converted to short (16bit) coordinates for use with external functions that demand that format. <p> <h3><a name="TQImage">TQImage</a></h3> -<p> <a href="qimage.html">TQImage</a> uses TQRgb for the colors - see <a href="#TQRgb">the changes to that</a>. +<p> <a href="ntqimage.html">TQImage</a> uses TQRgb for the colors - see <a href="#TQRgb">the changes to that</a>. <p> <h3><a name="TQPixmap">TQPixmap</a></h3> <p> <pre> TQPixmap::convertToImage()</pre> with bitmaps now guarantees that color0 pixels @@ -826,10 +826,10 @@ or - see the documentation to choose which is best for your application. NormalOptim is most like the TQt 1.x "TRUE" optimization. -<p> <h3><a name="TQMenuData">TQMenuData / <a href="qpopupmenu.html">TQPopupMenu</a></a></h3> +<p> <h3><a name="TQMenuData">TQMenuData / <a href="ntqpopupmenu.html">TQPopupMenu</a></a></h3> <p> 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 -<a href="qmenudata.html#insertItem">insertItem(...)</a> function used. +<a href="ntqmenudata.html#insertItem">insertItem(...)</a> function used. In TQt 2.x this confusing situation has been cleaned up: generated identifiers are always unique across the entire application. @@ -850,27 +850,27 @@ ownership manually. 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. -<p> Last but not least, <a href="qpopupmenu.html">TQPopupMenu</a> no longer inherits TQTableView. Instead, -it directly inherits <a href="qframe.html">TQFrame</a>. -<p> <h3><a name="TQValidator">TQValidator (<a href="qlineedit.html">TQLineEdit</a>, <a href="qcombobox.html">TQComboBox</a>, <a href="qspinbox.html">TQSpinBox</a>) </a></h3> +<p> Last but not least, <a href="ntqpopupmenu.html">TQPopupMenu</a> no longer inherits TQTableView. Instead, +it directly inherits <a href="ntqframe.html">TQFrame</a>. +<p> <h3><a name="TQValidator">TQValidator (<a href="ntqlineedit.html">TQLineEdit</a>, <a href="ntqcombobox.html">TQComboBox</a>, <a href="ntqspinbox.html">TQSpinBox</a>) </a></h3> <p> <pre> TQValidator::validate(...)</pre> and -<pre> TQValidator::fixup( <a href="qstring.html">TQString</a> & )</pre> +<pre> TQValidator::fixup( <a href="ntqstring.html">TQString</a> & )</pre> are now const functions. If your subclass reimplements validate() as a non-const function, you will get a compile error (validate was pure virtual). <p> In TQLineEdit, TQComboBox, and TQSpinBox, -setValidator(...) now takes a const pointer to a <a href="qvalidator.html">TQValidator</a>, and +setValidator(...) now takes a const pointer to a <a href="ntqvalidator.html">TQValidator</a>, 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 <a href="qobject.html">TQObject</a> on its own, with its own parent - you can easily set the same validator +a <a href="ntqobject.html">TQObject</a> 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. -<p> <h3><a name="TQFile">TQFile, <a href="qfileinfo.html">TQFileInfo</a>, <a href="qdir.html">TQDir</a></a></h3> -<p> File and directory names are now always Unicode strings (ie. <a href="qstring.html">TQString</a>). If you used TQString +<p> <h3><a name="TQFile">TQFile, <a href="ntqfileinfo.html">TQFileInfo</a>, <a href="ntqdir.html">TQDir</a></a></h3> +<p> File and directory names are now always Unicode strings (ie. <a href="ntqstring.html">TQString</a>). 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 <tt>unlink()</tt> function rather than <tt>TQFile::remove()</tt>, your code will probably @@ -888,12 +888,12 @@ boundingRect(<a href="qchar.html">TQChar</a>), but since char auto-converts to TQChar, you're not likely to run into problems with this. <p> <h3><a name="TQWindow">TQWindow</a></h3> -<p> This class (which was just <a href="qwidget.html">TQWidget</a> under a different name) has been +<p> This class (which was just <a href="ntqwidget.html">TQWidget</a> under a different name) has been removed. If you used it, do a global search-and-replace of the word "TQWindow" with "TQWidget". <p> <h3><a name="TQEvent">TQEvent</a></h3> -<p> <p> The global #define macros in qevent.h have been replaced by an -enum in <a href="qevent.html">TQEvent</a>. Use e.g. TQEvent::Paint instead of Event_Paint. Same +<p> <p> The global #define macros in ntqevent.h have been replaced by an +enum in <a href="ntqevent.html">TQEvent</a>. Use e.g. TQEvent::Paint instead of Event_Paint. Same for all of: Event_None, Event_Timer, @@ -931,7 +931,7 @@ Event_ActivateControl, Event_DeactivateControl, and Event_User. -<p> <p> The Q_*_EVENT macros in qevent.h have been deleted. Use an +<p> <p> The Q_*_EVENT macros in ntqevent.h have been deleted. Use an explicit cast instead. The macros were: Q_TIMER_EVENT, Q_MOUSE_EVENT, @@ -951,7 +951,7 @@ much testing of its values. <p> <h3>All the removed functions</h3> <p> All <a href="removed20.html">these functions</a> have been removed in TQt 2.x. Most are simply cases where "const char*" has changed to -"const <a href="qstring.html">TQString</a>&", or when an enumeration type has moved into the TQt:: +"const <a href="ntqstring.html">TQString</a>&", 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. <p> |