porting.html

qtopiaphone英文帮助,用于初学者和开发人员,初学者可以用来学习,开发人员可以用来资料查询.

that version, mystr = 'X' would <em>not</em> produce the expected
results and was always a programming error; in Qt 2.x, it works - making
a single-character string.
<p>
Also see <a href=#QStrList>QStrList</a>.
<p>
<dt><b>Signals and Slots</b></dt>
<dd>
Many signal/slots have changed from const char* to QString.  You will
 get run-time errors when you try to <pre> <a href="qobject.html#7f8e37">QObject::connect</a>()</pre>
<p>
 to the old
 signals and slots, usually with a message indicating the const QString&
 replacement signal/slot.
<p>
<dt><b>Optimize with Q2HELPER</b></dt>
<dd>
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.
<p>
<dt><b>QString::detach() is obsolete and removed</b></dt>
<dd>
Since QString is now always shared, this function does nothing.
Remove calls to QString::detach().
<p>
<dt><b>QString::resize(int size) is obsolete and removed</b></dt>
<dd>
Code using this to truncate a string should use
    <a href="qstring.html#bbfcaf">truncate(size-1)</a>.
Code using qstr.resize(0) should use qstr = QString::null.
Code calling resize(n) prior to using
    <a href="qstring.html#4c6de5">operator[]</a> up to n just remove
the resize(n) completely.
<p>
<dt><b>QString::size() is obsolete and removed</b></dt>
<dd>
Calls to this function must be replaced by
<a href="qstring.html#0ecbda">length()</a>+1.
<p>
<dt><b>QString::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 QString as an array of bytes, in which case use
QByteArray or QCString instead.
<p>
<dt><b>QString is not an array of bytes</b></dt>
<dd>
Code that uses QString as an array of bytes should use QByteArray
or a char[], <em>then</em> convert that to a QString if needed.
<p>
<dt><b>"string = 0"</b></dt>
<dd>
Assigning 0 to a QString should be assigning the null string,
ie. string = QString::null.
<p>
<dt><b>System functions</b></dt>
<dd>
You may find yourself needing latin1() for passing to the operating system
 or other libraries, and be tempted to use QCString 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 Qt will be tracking
 these improvements as they become more widespread.
<p>
<dt><b>Bugs removed</b></dt>
<dd>
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.
<p>
<dt><b>NULL pointers</b></dt>
<dd>
When converting "const char*" usage to QString in order to make your
 application fully Unicode-aware, use QString::null for the null value
 where you would have used 0 with char pointers.
<p>
<dt><b>QString is not null terminated</b></dt>
<dd>
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">QString</a> s = "fred";
   s[1] = '\0';
     // s.<a href="qstring.html#0ecbda">length</a>() == 4
     // s == "f\0ed"
     // s.<a href="qstring.html#ea8169">latin1</a>() == "f"
   s[1] = 'r';
     // s == "fred"
     // s.<a href="qstring.html#ea8169">latin1</a>() == "fred"
</pre>
<p>
 Especially look out for this type of code:
 <pre>   <a href="qstring.html">QString</a> s(2);
   s[0] = '?';
   s[1] = 0;
</pre>
<p>
 This creates a string 2 characters long.
 To find these problems while converting, you might like to
 add ASSERT(strlen(d->ascii)==d->len) inside
 <pre> <a href="qstring.html#ea8169">QString::latin1</a>()</pre>
.
<p>
<dt><b>QString or Standard C++ string?</b></dt>
<dd>
<p>
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 <em>the norm</em>
do programmers find them usable. Though it is possible to convert between
string and QString, it is less efficient than using QString throughout.
For example, when using:
<pre>    <a href="qlabel.html#bc5ea6">QLabel::setText</a>( const QString&amp; )
</pre>
<p>
if you use string, like this:
<pre>    void myclass::dostuffwithtext( const string&amp; str )
    {
        mylabel.setText( <a href="qstring.html">QString</a>(str.c_str()) );
    }
</pre>
<p>
that will create a (ASCII only) copy of str, stored in mylabel.
But this:
<pre>    void myclass::dostuffwithtext( const QString&amp; str )
    {
        mylabel.setText( str );
    }
</pre>
<p>
will make an implicitly shared reference to str in the QLabel - no copying
at all.  This function might be 10 nested function calls away from something
like this:
<pre>    void toplevelclass::initializationstuff()
    {
        doStuff( tr("Okay") );
    }
</pre>
<p>
At this point, in Qt 2.x, the tr() does a very fast dictionary lookup
through memory-mapped message files, returning some Unicode QString for
the appropriate language (the default being to just make a QString 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
though the system.  All occurrences of the translation of "Okay" can
potentially be shared.
<p>
</dl>
<p>
<h3><a name=QApplication>QApplication</a></h3>
<p>
In the function <pre> <a href="qapplication.html#1ee2d1">QApplication::setColorSpec</a>()</pre>
,
PrivateColor and TrueColor are obsolete.  Use ManyColor instead.
<p>
<h3><a name=QColor>QColor</a></h3>
<p>
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 Qt namespace.
In members of classes that inherit the Qt namespace-class (eg. QWidget
subclasses), you can use the unqualified names as before, but in global
functions (eg. main()), you need to qualify them:  Qt::red, Qt::white, etc.
See also the <a href=#QRgb>QRgb</a> section below.
<p>
<h3><a name=QRgb>QRgb</a></h3>
<p>
In QRgb (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
grey, green, or magenta).  You should port your code to use the
creator function qRgb(int r,int g,int b) and the
access functions qRed(QRgb), qBlue(QRgb), and qGreen(QRgb).
If you are using the alpha channel, it hasn't moved, but you should use
the functions qRgba(int,int,int,int) and qAlpha(QRgb). Note also that
QColor::pixel() does <i>not</i> return a QRgb (it never did on all platforms,
but your code may have assumed so on your platform) - this may also produce
strange color results - use QColor::rgb() if you want a QRgb.
<p>
<h3><a name=QDataStream>QDataStream</a></h3>
<p>The QDatastream serialization format of most Qt classes is changed
in Qt 2.x. Use <pre> <a href="qdatastream.html#364c56">QDataStream::setVersion</a>( 1 )</pre>
 to get a
datastream object that can read and write Qt 1.x format data streams.
<p>If you want to write Qt 1.x format datastreams, note the following
compatibility issues:
        <ul>
        <li>QString: Qt 1.x has no Unicode support, so strings will be
        serialized by writing the classic C string returned by <pre>        <a href="qstring.html#ea8169">QString::latin1</a>().</pre>
<li><a href=#QPoint>QPoint & al.</a>: Coordinates will be
        truncated to the Qt 1.x 16 bit format.
        </ul>
<p>
<h3><a name=QWidget>QWidget</a></h3>
<p>
<h4>QWidget::recreate()</h4>
<p>
This function is now called <a href="qwidget.html#4591aa">reparent()</a>.
<p>
<h4>QWidget::setAcceptFocus(bool)</h4>
<p>
This function is removed.
Calls like QWidget::setAcceptFocus(TRUE) should be replaced by
    <pre> <a href="qwidget.html#f92b0f">QWidget::setFocusPolicy</a>(StrongFocus)</pre>
, and
calls like QWidget::setAcceptFocus(FALSE) should be replaced by
    <pre> <a href="qwidget.html#f92b0f">QWidget::setFocusPolicy</a>(NoFocus)</pre>
.
Additional policies are TabFocus and ClickFocus.
<p>
<h4>QWidget::paintEvent()</h4>
<p>
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.
<p>
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
QPainter::setClipRegion() superfluous. Apart from the improved
consistency, the change is likely to reduce flicker and to make Qt
event slightly faster.
<p>
<h3><a name=QIODevice>QIODevice</a></h3>
<p>
The protected member QIODevice::index is renamed to QIODevice::ioIndex
to avoid warnings and to allow compilation with bad C libraries that
check every occurrence of the string "index" in the implementation, since
a compiler will not always catch cases like <pre>(uint)index</pre>
<p>
that need to be changed.
<p>
<h3><a name=QLabel>QLabel</a></h3>
<p>
<h4><pre> <a href="qframe.html#b11d00">QLabel::setMargin</a>()</pre>
</h4>
<p>
<pre> <a href="qframe.html#b11d00">QLabel::setMargin</a>()</pre>
 and<pre> <a href="qframe.html#cb5472">QLabel::margin</a>()</pre>
<p>
have been renamed to <pre> <a href="qlabel.html#9077ed">QLabel::setIndent</a>()</pre>
 and
<pre> <a href="qlabel.html#f68b83">QLabel::indent</a>()</pre>
, respectively. This was done to avoid
collision with QFrame::setMargin(), which is now virtual.
<p>
<h4><pre> <a href="qlabel.html#fb7d9d">QLabel::setMovie</a>()</pre>
</h4>
<p>
Previously, setting a movie on a label cleared the value of text().
Now it doesn't.  If you somehow used <tt>QLabel::text()</tt>
to detect if a
movie was set, you might have trouble.  This is unlikely.
<p>
<h3><a name=QDialog>QDialog</a></h3>
<p> The semantics of the parent pointer changed for non-modal dialogs:
In Qt-2.x, dialogs are always toplevel 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.
<p>
If the dialog belongs to a toplevel 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 QDialogs as child widgets will no longer work (it never really did).
If you think you might be doing this, put a breakpoint in
QDialog::QDialog() conditional on parent not being 0.
<p>
<h3><a name=QStrList>QStrList</a></h3>
<p>
Many methods that took a QStrList can now instead take a QStringList,
which is a real list of QString values.
<p>
To use QStringList rather than QStrList, change loops that look like this:
<pre>    <a href="qstrlist.html">QStrList</a> list = ...;
    const char* s;
    for ( s = list.<a href="qlist.html#e625f9">first</a>(); s; s = list.<a href="qlist.html#f95ddd">next</a>() ) {
        process(s);
    }
</pre>
<p>
to be like this:
<pre>    <a href="qstringlist.html">QStringList</a> list = ...;
    QStringList::ConstIterator i;
    for ( i = list.begin(); i != list.end(); ++i ) {
        process(*i);
    }
</pre>
<p>
In general, the QStrList functions are less efficient, building a temporary QStringList.
<p>
The following functions now use QStringList rather than QStrList
for return types/parameters.
<p>
<ul>
 <li><tt>void QFileDialog::setFilters(const QStrList&)</tt>
      becomes <tt>void QFileDialog::setFilters(const QStringList&)</tt>
 <li><tt>QStrList QFileDialog::getOpenFileNames(...)</tt>
      becomes <tt>QStringList QFileDialog::getOpenFileNames(...)</tt>
 <li><tt>bool QUrlDrag::decodeLocalFiles(QMimeSource*, QStrList&)</tt>
      becomes <tt>bool QUriDrag::decodeLocalFiles(QMimeSource*, QStringList&)</tt>
 <li><tt>const QStrList *QDir::entryList(...) const</tt>
      becomes <tt>QStringList QDir::entryList(...) const</tt>
        (note that the return type is no longer a pointer).  You may also
        choose to use encodedEntryList().
</ul>
<p>
The following functions are added:
<ul>
 <li><tt>QComboBox::insertStringList(const QStringList &, int index=-1)</tt>
 <li><tt>QListBox::insertStringList(const QStringList &,int index=-1)</tt>
</ul>
<p>
The rarely used static function <tt>void
QFont::listSubstitutions(QStrList*)</tt> is replaced by <tt>QStringList
QFont::substitutions()</tt>.
<p>