1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
|
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<!-- /home/espenr/tmp/qt-3.3.8-espenr-2499/qt-x11-free-3.3.8/doc/porting2.doc:36 -->
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
<title>Porting to TQt 2.x</title>
<style type="text/css"><!--
fn { margin-left: 1cm; text-indent: -1cm; }
a:link { color: #004faf; text-decoration: none }
a:visited { color: #672967; text-decoration: none }
body { background: #ffffff; color: black; }
--></style>
</head>
<body>
<table border="0" cellpadding="0" cellspacing="0" width="100%">
<tr bgcolor="#E5E5E5">
<td valign=center>
<a href="index.html">
<font color="#004faf">Home</font></a>
| <a href="classes.html">
<font color="#004faf">All Classes</font></a>
| <a href="mainclasses.html">
<font color="#004faf">Main Classes</font></a>
| <a href="annotated.html">
<font color="#004faf">Annotated</font></a>
| <a href="groups.html">
<font color="#004faf">Grouped Classes</font></a>
| <a href="functions.html">
<font color="#004faf">Functions</font></a>
</td>
<td align="right" valign="center"><img src="logo32.png" align="right" width="64" height="32" border="0"></td></tr></table><h1 align=center>Porting to TQt 2.x</h1>
<p> <p>
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:
<ul>
<li>To get access to all the new TQt 2.x features like the rich text
HTML subset for formatted labels, tooltips, online help etc.
and the much easier to use layout classes and widgets.
<li>To make your application truly international, with support
for Unicode and translations for the languages of the world.
<li>To allow your application to fit into the new look of the
Unix desktop with configurable, very powerful "themes". The
extended style system also integrates TQt applications better
on MS-Windows desktops. TQt will automatically chose the right
colors and fonts and obey global system setting changes.
<li>To stay up-to-date with the version of TQt that gets all the
new features and bug-fixes.
<li>To get more speed and smoother widgets display with all the
new anti-flicker changes in TQt.
<li>Most of all though, you want to port to TQt 2.x
so that your Wheel Mouse works!
</ul>
<p> <p>
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 <em>source</em> 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.
<p> To port code using TQt 1.x to use TQt 2.x:
<p> <ul>
<li> Briefly read the porting notes below to get an idea of what to expect.
<li> Be sure your code compiles and runs well on all your target platforms with TQt 1.x.
<li> Recompile with TQt 2.x. For each error, search below for related
identifiers (eg. function names, class names) - this documented is
structured to mention all relevant identifiers to facilitate such
searching, even if that makes it a little verbose.
<li> If you get stuck, ask on the qt-interest mailing list, or
Trolltech Technical Support if you're a Professional Edition
licensee.
</ul>
<p> Many very major projects, such as <a href="http://www.kde.org/">KDE</a>
have been port, so there is plenty of expertise in the collective conscious
that is the TQt Developer Community!
</p>
<p> <hr>
<p> <h2 align=center>The Porting Notes</h2>
<p> <ul>
<li><b><a href="#Namespace">Namespace</a></b>
<li><b><a href="#Virtual">Virtual Functions</a></b>
<li><b><a href="#Collection">Collection classes</a></b>
<li><b><a href="#DefaultParent">No Default 0 Parent Widget</a></b>
<li><b><a href="#DebugVsRelease">Debug vs. Release</a></b>
<li><b><a href="#TQApplication">TQApplication</a></b>
<li><b><a href="#TQClipboard">TQClipboard</a></b>
<li><b><a href="#TQColor">TQColor</a></b>
<li><b><a href="#TQDataStream">TQDataStream</a></b>
<li><b><a href="#TQDialog">TQDialog</a></b>
<li><b><a href="#TQDropSite">TQDropSite</a></b>
<li><b><a href="#TQEvent">TQEvent</a></b>
<li><b><a href="#TQFile">TQFile</a></b>
<li><b><a href="#TQFontMetrics">TQFontMetrics</a></b>
<li><b><a href="#TQIODevice">TQIODevice</a></b>
<li><b><a href="#TQLabel">TQLabel</a></b>
<li><b><a href="#TQLayout">TQLayout</a></b>
<li><b><a href="#TQListView">TQListView</a></b>
<li><b><a href="#TQMenuData">TQMenuData</a></b>
<li><b><a href="#TQMenuData">TQPopupMenu</a></b>
<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="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>
<li><b><a href="#TQStrList">TQStrList</a></b>
<li><b><a href="#TQString">TQString</a></b>
<li><b><a href="#TQTextStream">TQTextStream</a></b>
<li><b><a href="#TQUriDrag">TQUriDrag / TQUrlDrag</a></b>
<li><b><a href="#TQValidator">TQComboBox</a></b>
<li><b><a href="#TQValidator">TQLineEdit</a></b>
<li><b><a href="#TQValidator">TQSpinBox</a></b>
<li><b><a href="#TQValidator">TQValidator</a></b>
<li><b><a href="#TQWidget">TQWidget</a></b>
<li><b><a href="#TQWindow">TQWindow</a></b>
</ul>
<p> <hr>
<p> <h3><a name="Namespace">Namespace</a></h3>
<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 ntqnamespace.h),
which is inherited by
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,
TQt::LeftButton, TQt::AlignRight</code>, etc.
<p> <p>The <code>qt/bin/tqt20fix</code> script helps to fix the code that
needs adaption, though most code does not need changing.
<p> 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.
<p> <h3><a name="DefaultParent">No Default 0 Parent Widget</a></h3>
<p> 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.
<p> Note also that programs no longer need (or should) use 0 parent just
to indicate that a widget should be top-level. See
<pre> TQWidget::isTopLevel() </pre>
for details. See also the notes about
<a href="#TQMenuData">TQPopupMenu</a> and <a href="#TQDialog">TQDialog</a>
below.
<p> <h3><a name="Virtual">Virtual Functions</a></h3>
<p> <p> 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.
<p> <!-- warwick can check for additions to this with his qt-2-report -->
<ul>
<li><pre> TQWidget::setStyle(GUIStyle)</pre>
<li><pre> TQListView::addColumn(const char *, int)</pre>
<li><pre> TQListView::setColumnText(int, const char *)</pre>
<li><pre> TQListViewItem::setText(int, const char *)</pre>
<li><pre> TQMultiLineEdit::insertLine(const char *, int)</pre>
<li><pre> TQMultiLineEdit::insertAt(const char *, int, int, bool)</pre>
<li><pre> TQSpinBox::setPrefix(const char *)</pre>
<li><pre> TQSpinBox::setSuffix(const char *)</pre>
<li><pre> TQToolButton::setTextLabel(const char *, bool)</pre>
<li><pre> TQDoubleValidator::validate(TQString &, int &)</pre>
<li><pre> TQIntValidator::validate(TQString &, int &)</pre>
<li><pre> TQValidator::fixup(TQString &)</pre>
<li><pre> TQSlider::paintSlider(TQPainter *, const <a href="ntqrect.html">TQRect</a> &)</pre>
</ul>
<p> 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.
<p> <pre>
egrep -w 'setStyle|addColumn|setColumnText|setText...' *.h
</pre>
<p> Of course, you'll get a few false positives (eg. if you have a setText
function that is not in a subclass of <a href="qlistviewitem.html">TQListViewItem</a>).
<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="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 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.
This change has been made to avoid collisions with other namespaces.
<p> <p> The GCF global typedef is removed (it was not used in TQt).
<p> <h3><a name="DebugVsRelease">Debug vs. Release</a></h3>
<p> <p>The Q_ASSERT macro is now a null expression if the QT_CHECK_STATE flag
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="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="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>
To take full advantage of the new <a href="i18n.html#internationalization">Internationalization</a>
functionality in TQt 2.x, the following steps are required:
<p> <ul>
<li> Start converting all uses of "const char*" in parameters to
"const TQString&" - this can often be done mechanically, eg.
using Perl. Convert usage of char[] for temporary string
building to TQString (much software already uses TQString for
this purpose as it offers many more facilities).
<p> If you find that you are mixing usage of TQCString, TQString,
and <a href="qbytearray.html">TQByteArray</a>, this causes lots of unnecessary copying and
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="ntqstring.html">TQString</a>.
</p>
<li> Put a breakpoint in <pre> TQString::latin1()</pre>
to catch places where
Unicode information is being converted to ASCII (loosing
information if your user in not using Latin1). TQt has
a small number of calls to this - ignore those. As a stricter
alternative, compile your code with QT_NO_ASCII_CAST defined,
which hides the automatic conversion of TQString to const char*,
so you can catch problems at compile time.
</p>
<li> See the TQt <a href="i18n.html">Internationalization page</a>
for information about the full process of internationalizing
your software.
</ul>
<p> <p>
Points to note about the new TQString are:
<p> <dl compact>
<dt><b>Unicode</b></dt>
<dd>
TQt now uses Unicode throughout.
data() now returns a <em>const</em> 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.
<p> <dt><b>Automatic-expanding</b></dt>
<dd>
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>
<a href="qchar.html">TQChar</a> 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 <a href="shclass.html#implicit-sharing">implicit sharing</a> 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 <tt>mystring[123]</tt>
is a TQCharRef whenever <tt>mystring</tt> 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).
<p> <dt><b>Use TQString</b></dt>
<dd>
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="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>
<dd>
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.
<p> <dt><b>TQString is simpler</b></dt>
<dd>
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.
<p> <dt><b>Some hacks don't work</b></dt>
<dd>
This hack:
use_sub_string( &my_string[index] )
should be replaced by:
use_sub_string( my_string.mid(index) )
<p> <dt><b>TQString(const char*, int) is removed</b></dt>
<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="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="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().
<p>
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 <pre> TQString::sprintf()</pre>
. 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 <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="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
that version, mystr = 'X' would <em>not</em> produce the expected
results and was always a programming error; in TQt 2.x, it works - making
a single-character string.
<p> <p>
Also see <a href="#TQStrList">TQStrList</a>.
<p> <dt><b>Signals and Slots</b></dt>
<dd>
Many signal/slots have changed from const char* to TQString. You will
get run-time errors when you try to <pre> TQObject::connect()</pre>
to the old
signals and slots, usually with a message indicating the const TQString&
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>TQString::detach() is obsolete and removed</b></dt>
<dd>
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="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="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="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="ntqcstring.html">TQCString</a> instead.
<p> <dt><b>TQString is not an array of bytes</b></dt>
<dd>
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>
Assigning 0 to a TQString should be assigning the null string,
ie. string = TQString::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 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.
<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 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.
<p> <dt><b>TQString 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="ntqstring.html">TQString</a> s = "fred";
s[1] = '\0';
// s.<a href="ntqstring.html#length">length</a>() == 4
// s == "f\0ed"
// s.<a href="ntqstring.html#latin1">latin1</a>() == "f"
s[1] = 'r';
// s == "fred"
// s.<a href="ntqstring.html#latin1">latin1</a>() == "fred"
</pre>
Especially look out for this type of code:
<pre>
<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="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>
<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 <a href="ntqstring.html">TQString</a>, it is less efficient than using TQString throughout.
For example, when using:
<pre>
TQLabel::<a href="ntqlabel.html#setText">setText</a>( const <a href="ntqstring.html">TQString</a>& )
</pre>
if you use string, like this:
<pre>
void myclass::dostuffwithtext( const string& str )
{
mylabel.setText( TQString(str.c_str()) );
}
</pre>
that will create a (ASCII only) copy of str, stored in mylabel.
But this:
<pre>
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="ntqlabel.html">TQLabel</a> - 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>
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="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
though the system. All occurrences of the translation of "Okay" can
potentially be shared.
<p> </dl>
<p> <h3><a name="TQApplication">TQApplication</a></h3>
<p> In the function <pre> TQApplication::setColorSpec()</pre>
,
PrivateColor and TrueColor are obsolete. Use ManyColor instead.
<p> <h3><a name="TQColor">TQColor</a></h3>
<p> <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 TQt namespace.
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.
<p> <h3><a name="TQRgb">TQRgb</a></h3>
<p> 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 <a href="ntqcolor.html#qRgb">tqRgb</a>(int r,int g,int b) and the
access functions <a href="ntqcolor.html#qRed">tqRed</a>(TQRgb), <a href="ntqcolor.html#qBlue">tqBlue</a>(TQRgb), and <a href="ntqcolor.html#qGreen">tqGreen</a>(TQRgb).
If you are using the alpha channel, it hasn't moved, but you should use
the functions <a href="ntqcolor.html#qRgba">tqRgba</a>(int,int,int,int) and <a href="ntqcolor.html#qAlpha">tqAlpha</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="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>
to get a
datastream object that can read and write TQt 1.x format data streams.
<p> <p>If you want to write TQt 1.x format datastreams, note the following
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="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.
</ul>
<p> <h3><a name="TQWidget">TQWidget</a></h3>
<p> <h4>TQWidget::recreate()</h4>
<p>
This function is now called <a href="ntqwidget.html#reparent">reparent()</a>.
<p> <h4>TQWidget::setAcceptFocus(bool)</h4>
<p>
This function is removed.
Calls like TQWidget::setAcceptFocus(TRUE) should be replaced by
<pre> TQWidget::setFocusPolicy(StrongFocus)</pre>
, and
calls like TQWidget::setAcceptFocus(FALSE) should be replaced by
<pre> TQWidget::setFocusPolicy(NoFocus)</pre>
.
Additional policies are TabFocus and ClickFocus.
<p> <h4>TQWidget::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
<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="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>
that need to be changed.
<p> <h3><a name="TQLabel">TQLabel</a></h3>
<p> <h4><pre> TQLabel::setMargin()</pre>
</h4>
<p>
<pre> TQLabel::setMargin()</pre>
and<pre> TQLabel::margin()</pre>
have been renamed to <pre> TQLabel::setIndent()</pre>
and
<pre> TQLabel::indent()</pre>
, respectively. This was done to avoid
collision with <a href="ntqframe.html#setMargin">TQFrame::setMargin</a>(), which is now virtual.
<p> <h4><pre> TQLabel::setMovie()</pre>
</h4>
<p>
Previously, setting a movie on a label cleared the value of text().
Now it doesn't. If you somehow used <tt>TQLabel::text()</tt>
to detect if a
movie was set, you might have trouble. This is unlikely.
<p> <h3><a name="TQDialog">TQDialog</a></h3>
<p> <p> 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.
<p> <p>
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
<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="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="ntqstrlist.html">TQStrList</a> list = ...;
const char* s;
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="ntqstringlist.html">TQStringList</a> list = ...;
TQStringList::ConstIterator i;
for ( i = list.<a href="ntqvaluelist.html#begin">begin</a>(); i != list.<a href="ntqvaluelist.html#end">end</a>(); ++i ) {
process(*i);
}
</pre>
<p> In general, the TQStrList functions are less efficient, building a temporary TQStringList.
<p> The following functions now use TQStringList rather than TQStrList
for return types/parameters.
<p> <ul>
<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="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>
<p> The following functions are added:
<ul>
<li><tt>TQComboBox::insertStringList(const TQStringList &, int index=-1)</tt>
<li><tt>TQListBox::insertStringList(const TQStringList &,int index=-1)</tt>
</ul>
<p> The rarely used static function <tt>void
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="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,
not TQCOORD_MAX.
<p> <p> <a href="qboxlayout.html#addWidget">TQBoxLayout::addWidget()</a>
now interprets the <em>alignment</em> 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.)
<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="ntqwidget.html#setMinimumSize">setMinimumSize()</a>
and
<a href="ntqwidget.html#setFixedSize">setFixedSize()</a>
can be removed.
<a href="ntqlayout.html#activate">activate()</a> is no longer necessary.
<p> <p>
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="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="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="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>
<p> <p>
The protected function
<pre> TQMultiLineEdit::textWidth(TQString*)</pre>
changed to
<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="ntqpixmap.html">TQPixmap</a>, not a TQPixmap*.
The pixmap
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="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="ntqscrollview.html#viewport">viewport()</a> of a <a href="ntqlistview.html">TQListView</a>,
in which case,
override the
<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="ntqscrollview.html#contentsMoving">contentsMoving(int,int)</a>
are now positive rather than negative values, coinciding with
<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="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>
<pre> operator<<(TQTextStream&, TQChar&)</pre>
does not skip whitespace.
<pre> operator<<(TQTextStream&, char&)</pre>
does,
as was the case with TQt 1.x. This is for backward compatibility.
<p> <h3><a name="TQUriDrag">TQUriDrag</a></h3>
<p> The class TQUrlDrag is renamed to <a href="quridrag.html">TQUriDrag</a>, 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().
<p> <h3><a name="TQPainter">TQPainter</a></h3>
<p> <p> The GrayText painter flag has been removed. Use
<a href="ntqpainter.html#setPen">setPen( palette().disabled().foreground() )</a>
instead.
<p> <p> 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::.
<p> <h3><a name="TQPicture">TQPicture</a></h3>
<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,
set the formatVersion parameter to 1 in the TQPicture constructor.
<p> <p>For writing TQt 1.x format TQPictures, the compatibility issues of <a
href="#TQDataStream">TQDataStream</a> applies.
<p> <p>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.
<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="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>
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="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
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).
<p> <p>
<pre> TQPixmap::optimize(TRUE)</pre>
is replaced by
<pre> TQPixmap::setOptimization(TQPixmap::NormalOptim)</pre>
or
<pre> TQPixmap::setOptimization(TQPixmap::BestOptim)</pre>
- 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="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="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.
<p> If your code depends on generated ids
being equal to the item's index, a quick fix is to use
<pre> TQMenuData::indexOf(int id)</pre>
in the handling function instead. You may alternatively pass
<pre> TQMenuData::count()</pre>
as identifier when you insert the items.
<p> 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.
<p> 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.
<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="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="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="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="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
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
<pre> TQFile::encodeFilename()</pre>
and <pre> TQFile::decodeFilename()</pre>
- but do it
<em>just</em> 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 QT_NO_ASCII_CAST that
can help find potential problems.
<p> <h3><a name="TQFontMetrics">TQFontMetrics</a></h3>
<p> boundingRect(char) is replaced by
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="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 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,
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.
<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,
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.
<p> <p> TQChildEvents are now sent for all TQObjects, not just TQWidgets.
You may need to add extra checking if you use a <a href="qchildevent.html">TQChildEvent</a> without
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="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>
<!-- eof -->
<p><address><hr><div align=center>
<table width=100% cellspacing=0 border=0><tr>
<td>Copyright © 2007
<a href="troll.html">Trolltech</a><td align=center><a href="trademarks.html">Trademarks</a>
<td align=right><div align=right>TQt 3.3.8</div>
</table></div></address></body>
</html>
|
