<p>We also need to connect the tquit button to the form:</p>
<p>We also need to connect the quit button to the form:</p>
<ul><li><p>Click <b>New</b>.</p>
<li><p>Select tquitPushButton for Sender, clicked() for Signal, ConversionForm for Receiver, and close() for Slot.</p>
<li><p>Select quitPushButton for Sender, clicked() for Signal, ConversionForm for Receiver, and close() for Slot.</p>
</ul><p>We want to connect the calculate button and the other widgets, but the slot we want to use is not listed in the combobox. We will need to create a new slot so that we can select it from the list to complete our connections.</p>
<ul><li><p>Click <b>New</b>.</p>
<li><p>Select calculatePushButton for the Sender, clicked() for the Signal, and ConversionForm for the Receiver.</p>
<!-- index Code Editing --><!-- index Subclassing --><!-- index Forward declarations --><!-- index Includes --><!-- index Adding!Code --><!-- index Adding!Forward declarations --><!-- index Adding!Includes --><!-- index Adding!Class variables --><!-- index Class variables --><!-- index Deleting!Forward declarations --><!-- index Deleting!Includes --><!-- index Deleting!Class variables --><!-- index Forms!Forward declarations --><!-- index Forms!Class variables --><!-- index Forms!Code editing --><!-- index Forms!destructor --><!-- index Forms!constructor --><p>In the original version of <em>TQt Designer</em> if you wanted to provide code for a form you had to subclass the form and put your code in the subclass. This version fully supports the subclassing approach, but now provides an alternative: placing your code directly into forms. Writing code in <em>TQt Designer</em> is not tquite the same as subclassing, for example you cannot get direct access to the form's constructor or destructor. If you need code to be executed by the constructor create a slot called<!-- index init() --><tt>void init()</tt>; if it exists it will be called from the constructor. Similarly, if you need code to be executed before destruction create a slot called<!-- index destroy() --><tt>void destroy()</tt>. You can also add your own class variables which will be put in the generated constructor's code, and you can add forward declarations and any includes you retquire. To add a variable or declaration, right click the appropriate item, e.g. Class Variables, then click <b>New</b> then enter your text, e.g. <tt>TQString m_filename</tt>. If one or more items exist, right click to pop up a menu that has New, Edit and Delete options. If you want to enter multiple items, e.g. multiple include files or multiple data members, it is easiest to right click in the relevant section, then click <b>Edit</b> to invoke an Edit dialog. To edit code, just click the name of a function to invoke the code editor. Code editing and creating slots are covered later in the chapter.</p>
<!-- index Code Editing --><!-- index Subclassing --><!-- index Forward declarations --><!-- index Includes --><!-- index Adding!Code --><!-- index Adding!Forward declarations --><!-- index Adding!Includes --><!-- index Adding!Class variables --><!-- index Class variables --><!-- index Deleting!Forward declarations --><!-- index Deleting!Includes --><!-- index Deleting!Class variables --><!-- index Forms!Forward declarations --><!-- index Forms!Class variables --><!-- index Forms!Code editing --><!-- index Forms!destructor --><!-- index Forms!constructor --><p>In the original version of <em>TQt Designer</em> if you wanted to provide code for a form you had to subclass the form and put your code in the subclass. This version fully supports the subclassing approach, but now provides an alternative: placing your code directly into forms. Writing code in <em>TQt Designer</em> is not quite the same as subclassing, for example you cannot get direct access to the form's constructor or destructor. If you need code to be executed by the constructor create a slot called<!-- index init() --><tt>void init()</tt>; if it exists it will be called from the constructor. Similarly, if you need code to be executed before destruction create a slot called<!-- index destroy() --><tt>void destroy()</tt>. You can also add your own class variables which will be put in the generated constructor's code, and you can add forward declarations and any includes you retquire. To add a variable or declaration, right click the appropriate item, e.g. Class Variables, then click <b>New</b> then enter your text, e.g. <tt>TQString m_filename</tt>. If one or more items exist, right click to pop up a menu that has New, Edit and Delete options. If you want to enter multiple items, e.g. multiple include files or multiple data members, it is easiest to right click in the relevant section, then click <b>Edit</b> to invoke an Edit dialog. To edit code, just click the name of a function to invoke the code editor. Code editing and creating slots are covered later in the chapter.</p>
<!-- index Subclassing --><p>If you subclass the form you create your own<!-- index .cpp --><tt>.cpp</tt> files which can contain your own constructor, destructor, functions, slots, declarations and variables as your retquirements dictate. (See <ahref="designer-manual-6.html#1">Subclassing</a> for more information.)</p>
<h4><aname="6-5"></a>Editing the Code: Setting Up</h4>
<p>There is tquite a lot of code to include in the application, but this does not mean that a lot of typing is retquired! All the code is reproduced here so, if you're reading an electronic copy, you can simply cut and paste. If you're reading a print copy, all the code is provided in <tt>/tools/designer/examples/colortool</tt>; simply open the relevant <tt>.ui.h</tt> files and copy and paste from there into your own version of the project.</p>
<p>There is quite a lot of code to include in the application, but this does not mean that a lot of typing is retquired! All the code is reproduced here so, if you're reading an electronic copy, you can simply cut and paste. If you're reading a print copy, all the code is provided in <tt>/tools/designer/examples/colortool</tt>; simply open the relevant <tt>.ui.h</tt> files and copy and paste from there into your own version of the project.</p>
<blockquote>
<palign="center"><b> Cutting & Pasting Into the Code Editor</b></p>
<p>If you cut and paste code from this manual, because we've indented the code for readability, the code will be over-indented in <em>TQt Designer</em>. This is easily solved. Simply select the function containing the pasted code (either with the mouse, or <b>Shift+Arrow</b>s) and press <b>Tab</b>: this will make <em>TQt Designer</em> fix the indentation. Note that you must select the <em>entire</em> function, including its name and parameters.</p>
<p>If we left this code as-is, the user could by-pass our own termination code by clicking the main window's close (X) button. Since we want to give the user the option to save any unsaved changes we need to ensure that we intercept any attempt to close the application. To achieve this we delete the connection and add a new slot, <tt>closeEvent()</tt> which will intercept attempts to close the application and call our <tt>fileExit()</tt> function.</p>
<p>Click <tt>main.cpp</tt> in the Project Overview window. The file will appear in an editing window. Delete the connect line.</p>
<p>The code for this function is tquite long, but it isn't difficult. We start by setting a default color to white. If there are any colors in the <tt>m_colors</tt> map we set the default color to be the current color showing in the current view. We then invoke TQt's static <ahref="qcolordialog.html#getColor">getColor()</a> dialog, passing it the default color. (If the user cancels an invalid color is returned.)</p>
<p>The code for this function is quite long, but it isn't difficult. We start by setting a default color to white. If there are any colors in the <tt>m_colors</tt> map we set the default color to be the current color showing in the current view. We then invoke TQt's static <ahref="qcolordialog.html#getColor">getColor()</a> dialog, passing it the default color. (If the user cancels an invalid color is returned.)</p>
<p>If the user chose a color we want to show their chosen color in our custom dialog, so we create a pixmap and fill it with their chosen color. We create an instance of our ColorNameForm as a modal dialog (third argument is TRUE). We then call its <tt>setColors()</tt> function to set the colors in the <tt>m_colors</tt> map (so that the <tt>validate()</tt> function will work correctly). We set its colorLabel's pixmap to the pixmap we've just created, i.e. to a rectangle in the user's chosen color.</p>
<p>We execute (<tt>exec()</tt>) the dialog. If the user clicks OK (and the color name they've entered is valid), the call will return a true value. In this case we retrieve the name they've entered from the line edit and create a new entry in the <tt>m_colors</tt> map using the name the user has given and the color they chose.</p>
<p>At this point we could simply mark the views "dirty" and call repopulate. Instead we'll add the new color to each view directly and save the overhead of a full update (which might be considerable if we have thousands of colors).</p>
<p><em>TQt Designer</em> reads and writes <tt>.ui</tt> files, e.g. <tt>form.ui</tt>. The user interface compiler, <tt>uic</tt>, creates both a header file, e.g. <tt>form.h</tt>, and an implementation file, e.g. <tt>form.cpp</tt>, from the <tt>.ui</tt> file. The application code in <tt>main.cpp</tt><tt>#include</tt>s <tt>form.h</tt>. Typically <tt>main.cpp</tt> is used to instantiate the TQApplication object and start off the event loop.</p>
<p>While this approach is simple, it isn't sufficient for more complex dialogs. Complex dialogs tend to have tquite a lot of logic attached to the form's widgets, more logic than can usually be expressed with predefined signals and slots. One way of handling this extra logic is to write a controller class in the application code that adds functionality to the form. This is possible because <tt>uic</tt> generated classes expose a form's controls and their signals to the public space. The big disadvantage of this method is that it's not exactly TQt-style. If you were not using <em>TQt Designer</em>, you would almost always add the logic to the form itself, where it belongs.</p>
<p>While this approach is simple, it isn't sufficient for more complex dialogs. Complex dialogs tend to have quite a lot of logic attached to the form's widgets, more logic than can usually be expressed with predefined signals and slots. One way of handling this extra logic is to write a controller class in the application code that adds functionality to the form. This is possible because <tt>uic</tt> generated classes expose a form's controls and their signals to the public space. The big disadvantage of this method is that it's not exactly TQt-style. If you were not using <em>TQt Designer</em>, you would almost always add the logic to the form itself, where it belongs.</p>
<p>This is why the capability of adding custom slots and member variables to a form was added to <em>TQt Designer</em> early on. The big additional benefit with this approach is that you can use <em>TQt Designer</em> to connect signals to those custom slots, in the same elegant graphical way that is used to connect signals to predefined slots. The <tt>uic</tt> then adds an empty stub for each custom slot to the generated <tt>form.cpp</tt> implementation file.</p>
<p>The big question now is how to add custom implementation code to those custom slots. Adding code to the generated <tt>form.cpp</tt> is not an option, as this file gets recreated by the <tt>uic</tt> whenever the form changes -- and we don't want a combination of generated and handwritten code. There are two possible solutions, which we'll cover next.</p>
<p>We do <em>not</em> include the <tt>creditformbase.ui</tt> file since this file will be read at runtime, as we'll see shortly. We must include the <tt>tqui</tt> library since the functionality we retquire is not part of the standard TQt library.</p>
<h4><aname="2-2"></a>Creating main.cpp</h4>
<p>The<!-- index main.cpp --><tt>main.cpp</tt> is tquite standard. It will invoke the form we're going to create in <em>TQt Designer</em> as its main form. This form will then load and execute the dynamic dialog.</p>
<p>The<!-- index main.cpp --><tt>main.cpp</tt> is quite standard. It will invoke the form we're going to create in <em>TQt Designer</em> as its main form. This form will then load and execute the dynamic dialog.</p>
<p>We create a new instance of our MainForm class, set it to be the main widget, show it and enter the event loop in the <tt>app.exec()</tt> call.</p>
<h4><aname="2-3"></a>Creating the Main Form</h4>
<h5><aname="2-3-1"></a>Designing the Form</h5>
<oltype=1><li><p>Open the<!-- index receiver.pro --><tt>receiver.pro</tt> project file in <em>TQt Designer</em>. We'll create a dialog as our main window which we'll use to invoke the dynamic dialog. Press <b>Ctrl+N</b> to launch the <em>New File</em> dialog and click <b>OK</b> to get the default which is a dialog. Change the dialog's name to 'MainForm' and its caption to 'Main Form'. Add two buttons, one called 'creditPushButton' with the text '&Credit Dialog', and the other called 'tquitPushButton' with the text '&Quit'. (For each button click the <b>Push Button</b> toolbar button, then click the form. Change the properties in the property window to those we've just described.)</p>
<oltype=1><li><p>Open the<!-- index receiver.pro --><tt>receiver.pro</tt> project file in <em>TQt Designer</em>. We'll create a dialog as our main window which we'll use to invoke the dynamic dialog. Press <b>Ctrl+N</b> to launch the <em>New File</em> dialog and click <b>OK</b> to get the default which is a dialog. Change the dialog's name to 'MainForm' and its caption to 'Main Form'. Add two buttons, one called 'creditPushButton' with the text '&Credit Dialog', and the other called 'quitPushButton' with the text '&Quit'. (For each button click the <b>Push Button</b> toolbar button, then click the form. Change the properties in the property window to those we've just described.)</p>
<li><p>We will now add a couple of labels so that we can show the settings the user chose in the dynamic dialog. Click the <b>Text Label</b> toolbar button, then click the form below the Credit Dialog button. Change the label's <em>text</em> to 'Credit Rating'. Add another text label below the Quit button. Change its <em>name</em> to 'ratingTextLabel' and its <em>text</em> to 'Unrated'.</p>
<li><p>We'll now lay out the widgets. Click the form then press <b>Ctrl+G</b> (lay out in a grid).</p>
<li><!-- index Signals and Slots!Connecting to Close a Dialog --><p>We'll now handle the signals and slots connections. Invoke the <em>View and Edit Connections</em> dialog and connect the credit dialog button's clicked() signal to a new creditDialog() custom slot (which is created by clicking the <b>Edit Slots...</b> button). Now connect the Quit button's<!-- index clicked() --><tt>clicked()</tt> signal to the dialog's<!-- index accept() --><tt>accept()</tt> function.</p>
<p>To start, run <em>TQt Linguist</em>, either from the taskbar menu, or by double clicking the desktop icon, or type <tt>linguist</tt> (followed by <b>Enter</b>) at the command line. Once <em>TQt Linguist</em> has started choose <b>File|Open</b> from the menu bar and select a <tt>.ts</tt> translation source file to work on.</p>
<p><em>TQt Linguist</em>'s main window is divided into four main areas. The left hand side contains the Context list, the top right is the Source text area, the middle right is the translation area and the bottom right is the phrases and guesses area. We'll describe them in detail later.</p>
<p>Click on one of the contexts in the context list (left hand side) and then click on one of the phrases that appears in the Source text area (top right). The phrase will be copied into the translation area (middle right). Click under the word 'Translation' and type in the translation. Click <b>Ctrl+Enter</b> (Done & Next) to confirm that you have completed the translation and to move on to the next phrase that retquires translation.</p>
<p>The cycle of entering a translation then pressing <b>Ctrl+Enter</b> can be repeated until all the translations are done or until you finish the session. Linguist will attempt to fill the "phrases and guesses" area with possible translations from any open phrase books and any previous translations. Each has a keyboard shortcut, e.g. <b>Ctrl+1</b>, <b>Ctrl+2</b>, etc., which you can use to copy the guess into the Translation area. (Mouse users can double click a phrase or guess to move it into the Translation area.) At the end of the session choose <b>File|Save</b> from the menu bar and then <b>File|Exit</b> to tquit.</p>
<p>The cycle of entering a translation then pressing <b>Ctrl+Enter</b> can be repeated until all the translations are done or until you finish the session. Linguist will attempt to fill the "phrases and guesses" area with possible translations from any open phrase books and any previous translations. Each has a keyboard shortcut, e.g. <b>Ctrl+1</b>, <b>Ctrl+2</b>, etc., which you can use to copy the guess into the Translation area. (Mouse users can double click a phrase or guess to move it into the Translation area.) At the end of the session choose <b>File|Save</b> from the menu bar and then <b>File|Exit</b> to quit.</p>
<h3><aname="2"></a>TQt Linguist's Main Window</h3>
<h4><aname="2-1"></a>Context List</h4>
<!-- index Contexts!for Translation --><p>This appears at the left hand side of the main window by default. The first column, 'Done', identifies whether or not the translations for the context have been done. A tick indicates that all the translations have been done and are valid. A question mark indicates that one or more translations have not been done or have failed validation. The second column, 'Context' is the name of the context in which the translation phrases appear. The third column, 'Items' shows two numbers, the first is the number of translations that have been done, and the second is the number of phrases that are in the context; if the numbers are equal then all the translations have been done. Note that a greyed out tick indicates an obsolete translation, i.e. a phrase that was translated in a previous version of the application but which does not occur in the new version.</p>
<p>It is strongly recommended that the two argument form of <tt>tr()</tt> is used for Ctrl key accelerators. The second argument is the only clue the translator has as to the function performed by the accelerator.</p>
@ -336,7 +336,7 @@ TRANSLATIONS = tt2_fr.ts \
<pre> ArrowPad *ap = new ArrowPad( this, "arrow pad" );
</pre>
<p>We also call <tt>MainWindow::tr()</tt> twice, once for the menu item and once for the accelerator.</p>
<!-- index Ctrl Key --><!-- index Alt Key --><pre> file-><ahref="qmenudata.html#insertItem">insertItem</a>( <ahref="qobject.html#tr">tr</a>("E&xit"), qApp, SLOT(<ahref="qapplication.html#tquit">tquit</a>()),
<!-- index Ctrl Key --><!-- index Alt Key --><pre> file-><ahref="qmenudata.html#insertItem">insertItem</a>( <ahref="qobject.html#tr">tr</a>("E&xit"), qApp, SLOT(<ahref="qapplication.html#quit">quit</a>()),
<p>Note the use of <tt>tr()</tt> to support different keys in other languages. "Ctrl+Q" is a good choice for Quit in English, but a Dutch translator might want to use "Ctrl+A" (for Afsluiten) and a German translator "Strg+E" (for Beenden). When using <tt>tr()</tt> for Ctrl key accelerators, the two argument form should be used with the second argument describing the function that the accelerator performs.</p>
<!-- index lupdate --><!-- index tt3_pt.ts --><p>Now run <ahref="linguist-manual-2.html#2">lupdate</a> and open <tt>tt3_pt.ts</tt> with <em>TQt Linguist</em>. You should now see two changes.</p>
<p>First, the translation source file now contains <em>three</em> "Enabled", "Disabled" pairs. The first pair is marked "(obs.)" signifying that they are obsolete. This is because these texts appeared in <tt>tr()</tt> calls that have been replaced by new calls with two arguments. The second pair has "two-sided" as their comment, and the third pair has "colors" as their comment. The comments are shown in the <em>Source text and comments</em> area in <em>TQt Linguist</em>.</p>
<p>Second, the translation text "Ativado" and "Desativado" have been automatically used as translations for the new "Enabled" and "Disabled" texts, again to minimize the translator's work. Of course in this case these are not correct for the second occurrence of each word, but they provide a good starting point.</p>
<p>Change the second "Ativado" into "Ativadas" and the second "Desativado" into "Desativadas", then save and tquit. Run <ahref="linguist-manual-2.html#3">lrelease</a> to obtain an up-to-date binary <tt>tt3_pt.qm</tt> file, and run Troll Print (or rather Troll Imprimir).</p>
<p>Change the second "Ativado" into "Ativadas" and the second "Desativado" into "Desativadas", then save and quit. Run <ahref="linguist-manual-2.html#3">lrelease</a> to obtain an up-to-date binary <tt>tt3_pt.qm</tt> file, and run Troll Print (or rather Troll Imprimir).</p>
<li><p>Two-sided - unmarked, i.e. untranslated.</p>
</ul></ul><p>Notice that <ahref="linguist-manual-2.html#2">lupdate</a> works hard behind the scenes to make revisions easier, and it's pretty smart with numbers.</p>
<p>Go over the translations in <tt>MainWindow</tt> and mark these as "done". Translate "<b>TROLL PRINT</b>" as "<b>TROLL IMPRIMIR</b>". When you're translating "Two-sided", press the <em>Guess Again</em> button to translate "Two-sided", but change the "2" into "Dois".</p>
<p>Save and tquit, then run <ahref="linguist-manual-2.html#3">lrelease</a>. The Portuguese version should look like this:</p>
<p>Save and quit, then run <ahref="linguist-manual-2.html#3">lrelease</a>. The Portuguese version should look like this:</p>
@ -69,7 +69,7 @@ existing callback functions found in <tt>todo.cpp</tt> and <tt>actions.cpp</tt>.
<trbgcolor="#f0f0f0"><tdvalign="top">Save <tdvalign="top"><tt>MainWindow::fileSave()</tt><tdvalign="top">calls the <tt>SaveIt()</tt> callback
<trbgcolor="#d0d0d0"><tdvalign="top">Save As <tdvalign="top"><tt>MainWindow::fileSaveAs()</tt><tdvalign="top">calls the <tt>Save()</tt> callback
<trbgcolor="#f0f0f0"><tdvalign="top">Print <tdvalign="top"><tt>MainWindow::filePrint()</tt><tdvalign="top">calls the <tt>ShowPrintDialog()</tt> callback
<trbgcolor="#a2c511"><thvalign="top"colspan="3"rowspan="1"> Selected menu
<trbgcolor="#f0f0f0"><tdvalign="top">Properties <tdvalign="top"><tt>MainWindow::selProperties()</tt><tdvalign="top">calls the <tt>EditPage()</tt> callback
<trbgcolor="#d0d0d0"><tdvalign="top">New <tdvalign="top"><tt>MainWindow::selNewPage()</tt><tdvalign="top">calls the <tt>NewPage()</tt> callback
@ -75,7 +75,7 @@ This could be, for example, a protocol which can read pictures from a
digital camera using a serial connection.
<p><h2> Working Network Protocol independently with <ahref="qurloperator.html">TQUrlOperator</a> and <ahref="qnetworkoperation.html">TQNetworkOperation</a>
</h2>
<aname="2"></a><p> It is tquite easy to just use existing network protocol implementations
<aname="2"></a><p> It is quite easy to just use existing network protocol implementations
and operate on URLs. For example, downloading a file from an FTP
server to the local filesystem can be done with following code:
<p> The windows are closed in random order, until one window does not
accept the close event.
<p><p>See also <ahref="qwidget.html#close">TQWidget::close</a>(), <ahref="qwidget.html#closeEvent">TQWidget::closeEvent</a>(), <ahref="#lastWindowClosed">lastWindowClosed</a>(), <ahref="#tquit">tquit</a>(), <ahref="#topLevelWidgets">topLevelWidgets</a>(), and <ahref="qwidget.html#isTopLevel-prop">TQWidget::isTopLevel</a>.
<p><p>See also <ahref="qwidget.html#close">TQWidget::close</a>(), <ahref="qwidget.html#closeEvent">TQWidget::closeEvent</a>(), <ahref="#lastWindowClosed">lastWindowClosed</a>(), <ahref="#quit">quit</a>(), <ahref="#topLevelWidgets">topLevelWidgets</a>(), and <ahref="qwidget.html#isTopLevel-prop">TQWidget::isTopLevel</a>.
<p>
<p>Examples: <ahref="qaction-application-example.html#x1127">action/application.cpp</a>, <ahref="simple-application-example.html#x1544">application/application.cpp</a>, <ahref="helpviewer-example.html#x980">helpviewer/helpwindow.cpp</a>, <ahref="mdi-example.html#x2020">mdi/application.cpp</a>, and <ahref="qwerty-example.html#x358">qwerty/qwerty.cpp</a>.
@ -803,7 +803,7 @@ it before you create the TQApplication object.
</h3>
Enters the main event loop and waits until <ahref="#exit">exit</a>() is called or the
main widget is destroyed, and returns the value that was set to
exit() (which is 0 if exit() is called via <ahref="#tquit">tquit</a>()).
exit() (which is 0 if exit() is called via <ahref="#quit">quit</a>()).
<p> It is necessary to call this function to start event handling. The
main event loop receives events from the window system and
dispatches these to the application widgets.
@ -815,7 +815,7 @@ exec() to start a local event loop.
special function whenever there are no pending events, use a
<ahref="qtimer.html">TQTimer</a> with 0 timeout. More advanced idle processing schemes can
be achieved using <ahref="#processEvents">processEvents</a>().
<p><p>See also <ahref="#tquit">tquit</a>(), <ahref="#exit">exit</a>(), <ahref="#processEvents">processEvents</a>(), and <ahref="#setMainWidget">setMainWidget</a>().
<p><p>See also <ahref="#quit">quit</a>(), <ahref="#exit">exit</a>(), <ahref="#processEvents">processEvents</a>(), and <ahref="#setMainWidget">setMainWidget</a>().
<p>Examples: <ahref="helpsystem-example.html#x2700">helpsystem/main.cpp</a>, <ahref="qdialog.html#x2132">life/main.cpp</a>, <ahref="archivesearch-example.html#x486">network/archivesearch/main.cpp</a>, <ahref="ftpclient-example.html#x777">network/ftpclient/main.cpp</a>, <ahref="qaxserver-example-opengl.html#x2731">opengl/main.cpp</a>, <ahref="tutorial1-01.html#x2283">t1/main.cpp</a>, and <ahref="tutorial1-04.html#x2303">t4/main.cpp</a>.
<p> Note that unlike the C library function of the same name, this
function <em>does</em> return to the caller -- it is event processing that
stops.
<p><p>See also <ahref="#tquit">tquit</a>() and <ahref="#exec">exec</a>().
<p><p>See also <ahref="#quit">quit</a>() and <ahref="#exec">exec</a>().
<p>Examples: <ahref="canvas-chart-example.html#x2875">chart/chartform.cpp</a>, <ahref="extension-dialog-example.html#x2865">extension/mainform.ui.h</a>, and <ahref="picture-example.html#x106">picture/picture.cpp</a>.
<p><p>See also <ahref="#exit">exit</a>(), <ahref="#aboutToQuit">aboutToQuit</a>(), <ahref="#lastWindowClosed">lastWindowClosed</a>(), and <ahref="qaction.html">TQAction</a>.
@ -1468,12 +1468,12 @@ TQApplication does <em>not</em> take ownership of the <em>mainWidget</em>, so
if you create your main widget on the heap you must delete it
yourself.
<p> You need not have a main widget; connecting <ahref="#lastWindowClosed">lastWindowClosed</a>() to
<ahref="#tquit">tquit</a>() is an alternative.
<ahref="#quit">quit</a>() is an alternative.
<p> For X11, this function also resizes and moves the main widget
according to the <em>-geometry</em> command-line option, so you should
set the default geometry (using <ahref="qwidget.html#setGeometry">TQWidget::setGeometry</a>()) before
@ -242,7 +242,7 @@ and exec() to return <em>r</em>.
main widget, the application terminates. If the dialog is the
last window closed, the <ahref="qapplication.html#lastWindowClosed">TQApplication::lastWindowClosed</a>() signal is
emitted.
<p><p>See also <ahref="#accept">accept</a>(), <ahref="#reject">reject</a>(), <ahref="qapplication.html#mainWidget">TQApplication::mainWidget</a>(), and <ahref="qapplication.html#tquit">TQApplication::tquit</a>().
<p><p>See also <ahref="#accept">accept</a>(), <ahref="#reject">reject</a>(), <ahref="qapplication.html#mainWidget">TQApplication::mainWidget</a>(), and <ahref="qapplication.html#quit">TQApplication::quit</a>().
@ -165,7 +165,7 @@ exec() to start a local event loop.
special function whenever there are no pending events, use a
<ahref="qtimer.html">TQTimer</a> with 0 timeout. More advanced idle processing schemes can
be achieved using <ahref="#processEvents">processEvents</a>().
<p><p>See also <ahref="qapplication.html#tquit">TQApplication::tquit</a>(), <ahref="#exit">exit</a>(), and <ahref="#processEvents">processEvents</a>().
<p><p>See also <ahref="qapplication.html#quit">TQApplication::quit</a>(), <ahref="#exit">exit</a>(), and <ahref="#processEvents">processEvents</a>().
@ -252,7 +252,7 @@ can get keyboard focus by tabbing, clicking and through the use of
the mouse wheel.
<p> New items can be inserted using <ahref="#insertItem">insertItem</a>(), <ahref="#insertStrList">insertStrList</a>() or
<ahref="#insertStringList">insertStringList</a>(). <ahref="#inSort">inSort</a>() is obsolete because this method is
tquite inefficient. It's preferable to insert the items normally
quite inefficient. It's preferable to insert the items normally
and call <ahref="#sort">sort</a>() afterwards, or to insert a sorted <ahref="qstringlist.html">TQStringList</a>().
<p> By default, vertical and horizontal scroll bars are added and
removed as necessary. <ahref="qscrollview.html#setHScrollBarMode">setHScrollBarMode</a>() and <ahref="qscrollview.html#setVScrollBarMode">setVScrollBarMode</a>()
@ -532,7 +532,7 @@ item. The argument is a pointer to the new current item.
<p><em>qmake</em> is an easy-to-use tool from Trolltech that creates makefiles for development projects across different platforms. <em>qmake</em> simplifies the generation of makefiles so that only a few lines of information are needed to create a makefile. <em>qmake</em> can be used for any software project whether it is written in TQt or not, although it also contains additional features to support TQt development.</p>
<p><em>qmake</em> generates a makefile based on the information in a project file. Project files are created by the developer. Project files are usually simple, but can be tquite sophisticated if retquired. <em>qmake</em> can also generate projects for Microsoft Visual studio without having to change the project file.</p>
<p><em>qmake</em> generates a makefile based on the information in a project file. Project files are created by the developer. Project files are usually simple, but can be quite sophisticated if retquired. <em>qmake</em> can also generate projects for Microsoft Visual studio without having to change the project file.</p>
<p>Before <em>qmake</em> can be used to build makefiles, the QMAKESPEC environment variable must be set to the platform-compiler combination that is being used on the system. The QMAKESPEC environment variable tells qmake where to look to find platform and compiler specific information. This ensures that the right libraries are used, and that the generated makefile uses the correct syntax. A list of the currently supported platform-compiler combinations can be found in qt/mkspecs. Just set your environment variable to one of the directories listed.</p>
<li><p>The name of a platform-compiler combination. In this case, <em>qmake</em> will search in the directory specified by the QTDIR environment variable.</p>
</ul><p>Note: the QMAKESPEC path will automatically be added to the <ahref="qmake-manual-8.html#INCLUDEPATH">INCLUDEPATH</a> system variable.</p>
<p>It is common on UNIX to be able to install from the same utility as you build with (e.g make install). For this <em>qmake</em> has introduce the concept of an install set. The notation for this is tquite simple, first you fill in an "object" in qmake for example:</p>
<p>It is common on UNIX to be able to install from the same utility as you build with (e.g make install). For this <em>qmake</em> has introduce the concept of an install set. The notation for this is quite simple, first you fill in an "object" in qmake for example:</p>
<pre>
documentation.path = /usr/local/program/doc
documentation.files = docs/*
@ -698,7 +698,7 @@ QMAKE_VERS = $$[QMAKE_VERSION]
<li><p>QMAKE_EXT_H - Changes interpretation all files with these suffixes to be C header files.</p>
<p>qmake often tries to be all things to all build tools, this is often less than ideal when you really need to run special platform dependent commands. This can be achieved with specific instructions to the different qmake backends (currently this is only supported by the UNIX <ahref="qmake-manual-8.html#MAKEFILE_GENERATOR">generator</a>).</p>
<p>The interfaces to customizing the Makefile are done through "objects" as in other places in qmake. The notation for this is tquite simple, first you fill in an "object" in qmake for example:</p>
<p>The interfaces to customizing the Makefile are done through "objects" as in other places in qmake. The notation for this is quite simple, first you fill in an "object" in qmake for example:</p>
@ -249,7 +249,7 @@ Returns TRUE if this is a valid socket; otherwise returns FALSE.
</h3>
Specifies how many pending connections a server socket can have.
Returns TRUE if the operation was successful; otherwise returns
FALSE. A <em>backlog</em> value of 50 is tquite common.
FALSE. A <em>backlog</em> value of 50 is quite common.
<p> The <ahref="#listen">listen</a>() call only applies to sockets where <ahref="#type">type</a>() is <ahref="#Type-enum">Stream</a>, i.e. not to <ahref="#Type-enum">Datagram</a> sockets. listen() must not be
called before <ahref="#bind">bind</a>() or after <ahref="#accept">accept</a>().
<p><p>See also <ahref="#bind">bind</a>() and <ahref="#accept">accept</a>().
<p> You can also display another text (typically in a <ahref="qstatusbar.html">status bar),</a> courtesy of <ahref="qtooltipgroup.html">TQToolTipGroup</a>. This example
assumes that <em>grp</em> is a <tt>TQToolTipGroup *</tt> and is already
connected to the appropriate status bar:
<p><pre>
TQToolTip::<ahref="#add">add</a>( tquitButton, "Leave the application", grp,
TQToolTip::<ahref="#add">add</a>( quitButton, "Leave the application", grp,
"Leave the application, prompting to save if necessary" );
TQToolTip::<ahref="#add">add</a>( closeButton, "Close this window", grp,
"Close this window, prompting to save if necessary" );
@ -569,7 +569,7 @@ If not, it will be a child of <em>parent</em>, and be constrained by <em>parent<
<ahref="qt.html#WidgetFlags">widget flag</a>).
<li><tt>const char *name = 0</tt> is the widget name of the new
widget. You can access it using <ahref="qobject.html#name">name</a>(). The widget name is little
used by programmers but is tquite useful with GUI builders such as
used by programmers but is quite useful with GUI builders such as
<em>TQt Designer</em> (you can name a widget in <em>TQt Designer</em>, and
<ahref="qobject.html#connect">connect</a>() to it using the name in your code). The <ahref="qobject.html#dumpObjectTree">dumpObjectTree</a>()
debugging function also uses it.
@ -606,10 +606,10 @@ somewhere else, then releases, <em>your</em> widget receives the release
event. There is one exception: if a popup menu appears while the
mouse button is held down, this popup immediately steals the mouse
events.
<p><li><ahref="#mouseDoubleClickEvent">mouseDoubleClickEvent</a>() - not tquite as obvious as it might seem.
<p><li><ahref="#mouseDoubleClickEvent">mouseDoubleClickEvent</a>() - not quite as obvious as it might seem.
If the user double-clicks, the widget receives a mouse press event
(perhaps a mouse move event or two if they don't hold the mouse
tquite steady), a mouse release event and finally this event. It is
quite steady), a mouse release event and finally this event. It is
<em>not possible</em> to distinguish a click from a double click until you've
seen whether the second click arrives. (This is one reason why most GUI
books recommend that double clicks be an extension of single clicks,
@ -855,7 +855,7 @@ no matter if the widget is visible or not.
last visible top level widget is closed.
<p> Note that closing the <ahref="qapplication.html#mainWidget">TQApplication::mainWidget</a>() terminates the
application.
<p><p>See also <ahref="#closeEvent">closeEvent</a>(), <ahref="qcloseevent.html">TQCloseEvent</a>, <ahref="#hide">hide</a>(), <ahref="qapplication.html#tquit">TQApplication::tquit</a>(), <ahref="qapplication.html#setMainWidget">TQApplication::setMainWidget</a>(), and <ahref="qapplication.html#lastWindowClosed">TQApplication::lastWindowClosed</a>().
<p><p>See also <ahref="#closeEvent">closeEvent</a>(), <ahref="qcloseevent.html">TQCloseEvent</a>, <ahref="#hide">hide</a>(), <ahref="qapplication.html#quit">TQApplication::quit</a>(), <ahref="qapplication.html#setMainWidget">TQApplication::setMainWidget</a>(), and <ahref="qapplication.html#lastWindowClosed">TQApplication::lastWindowClosed</a>().
<p> connect() is perhaps <em>the</em> most central feature of TQt.
Note that connect() is a static function in <ahref="qobject.html">TQObject</a>. Do not confuse it
@ -97,8 +97,8 @@ that inherit TQObject, directly or indirectly). Every TQt object can have
both <tt>signals</tt> (to send messages) and <tt>slots</tt> (to receive messages). All
widgets are TQt objects. They inherit <ahref="qwidget.html">TQWidget</a> which in turn inherits
TQObject.
<p> Here, the <em>clicked()</em> signal of <em>tquit</em> is connected to the <em>tquit()</em> slot of <em>a</em>, so that when the button is clicked, the
application tquits.
<p> Here, the <em>clicked()</em> signal of <em>quit</em> is connected to the <em>quit()</em> slot of <em>a</em>, so that when the button is clicked, the
application quits.
<p> The <ahref="signalsandslots.html">Signals and Slots</a> documentation
describes this topic in detail.
<p><h2> Behavior
@ -111,7 +111,7 @@ makefile and build the application.)
</h2>
<aname="3"></a><p> Try to resize the window. Press the button. Oops! That connect()
would seem to make some difference.
<p> Are there any other signals in <ahref="qpushbutton.html">TQPushButton</a> you can connect to tquit?
<p> Are there any other signals in <ahref="qpushbutton.html">TQPushButton</a> you can connect to quit?
Hint: The TQPushButton inherits most of its behavior from <ahref="qbutton.html">TQButton</a>.
<p> You're now ready for <ahref="tutorial1-03.html">Chapter 3.</a>
This signal is emitted when the application is about to tquit the main event loop, e.g. when the event loop level drops to zero. This may happen either after a call to tquit() from inside the application or when the users shuts down the entire desktop session.
This signal is emitted when the application is about to quit the main event loop, e.g. when the event loop level drops to zero. This may happen either after a call to quit() from inside the application or when the users shuts down the entire desktop session.
.PP
The signal is particularly useful if your application has to do some last-second cleanup. Note that no user interaction is possible in this state.
The windows are closed in random order, until one window does not accept the close event.
.PP
See also QWidget::close(), QWidget::closeEvent(), lastWindowClosed(), tquit(), topLevelWidgets(), and QWidget::isTopLevel.
See also QWidget::close(), QWidget::closeEvent(), lastWindowClosed(), quit(), topLevelWidgets(), and QWidget::isTopLevel.
.PP
Examples:
.)l action/application.cpp, application/application.cpp, helpviewer/helpwindow.cpp, mdi/application.cpp, and qwerty/qwerty.cpp.
@ -883,7 +883,7 @@ See also QEventLoop.
.PP
Example: distributor/distributor.ui.h.
.SH "int QApplication::exec ()"
Enters the main event loop and waits until exit() is called or the main widget is destroyed, and returns the value that was set to exit() (which is 0 if exit() is called via tquit()).
Enters the main event loop and waits until exit() is called or the main widget is destroyed, and returns the value that was set to exit() (which is 0 if exit() is called via quit()).
.PP
It is necessary to call this function to start event handling. The main event loop receives events from the window system and dispatches these to the application widgets.
.PP
@ -891,7 +891,7 @@ Generally speaking, no user interaction can take place before calling exec(). As
.PP
To make your application perform idle processing, i.e. executing a special function whenever there are no pending events, use a QTimer with 0 timeout. More advanced idle processing schemes can be achieved using processEvents().
.PP
See also tquit(), exit(), processEvents(), and setMainWidget().
See also quit(), exit(), processEvents(), and setMainWidget().
.PP
Examples:
.)l helpsystem/main.cpp, life/main.cpp, network/archivesearch/main.cpp, network/ftpclient/main.cpp, opengl/main.cpp, t1/main.cpp, and t4/main.cpp.
@ -904,7 +904,7 @@ By convention, a \fIretcode\fR of 0 means success, and any non-zero value indica
.PP
Note that unlike the C library function of the same name, this function \fIdoes\fR return to the caller -- it is event processing that stops.
.PP
See also tquit() and exec().
See also quit() and exec().
.PP
Examples:
.)l chart/chartform.cpp, extension/mainform.ui.h, and picture/picture.cpp.
@ -982,7 +982,7 @@ See also sessionId(), commitData(), and saveState().
This signal is emitted when the user has closed the last top level window.
.PP
The signal is very useful when your application has many top level widgets but no main widget. You can then connect it to the tquit() slot.
The signal is very useful when your application has many top level widgets but no main widget. You can then connect it to the quit() slot.
.PP
For convenience, this signal is \fInot\fR emitted for transient top level widgets such as popup menus and dialogs.
.PP
@ -1120,18 +1120,18 @@ This function is useful for adapting Qt to situations where the event processing
Using this function in new applications may be an indication of design problems.
.PP
See also processEvents(), exec(), and QTimer.
.SH "void QApplication::tquit ()\fC [slot]\fR"
.SH "void QApplication::quit ()\fC [slot]\fR"
Tells the application to exit with return code 0 (success). Equivalent to calling QApplication::exit( 0 ).
.PP
It's common to connect the lastWindowClosed() signal to tquit(), and you also often connect e.g. QButton::clicked() or signals in QAction, QPopupMenu or QMenuBar to it.
It's common to connect the lastWindowClosed() signal to quit(), and you also often connect e.g. QButton::clicked() or signals in QAction, QPopupMenu or QMenuBar to it.
.PP
Example:
.PP
.nf
.br
QPushButton *tquitButton = new QPushButton( "Quit" );
QPushButton *quitButton = new QPushButton( "Quit" );
@ -1404,11 +1404,11 @@ Sets the application's main widget to \fImainWidget\fR.
.PP
In most respects the main widget is like any other widget, except that if it is closed, the application exits. Note that QApplication does \fInot\fR take ownership of the \fImainWidget\fR, so if you create your main widget on the heap you must delete it yourself.
.PP
You need not have a main widget; connecting lastWindowClosed() to tquit() is an alternative.
You need not have a main widget; connecting lastWindowClosed() to quit() is an alternative.
.PP
For X11, this function also resizes and moves the main widget according to the \fI-geometry\fR command-line option, so you should set the default geometry (using QWidget::setGeometry()) before calling setMainWidget().
.PP
See also mainWidget(), exec(), and tquit().
See also mainWidget(), exec(), and quit().
.PP
Examples:
.)l chart/main.cpp, helpsystem/main.cpp, life/main.cpp, network/ftpclient/main.cpp, opengl/main.cpp, t1/main.cpp, and t4/main.cpp.
This style provides a slightly improved Motif look similar to some versions of the Common Desktop Environment (CDE). The main differences are thinner frames and more modern radio buttons and checkboxes. Together with a dark background and a bright text/foreground color, the style looks tquite attractive (at least for Motif fans).
This style provides a slightly improved Motif look similar to some versions of the Common Desktop Environment (CDE). The main differences are thinner frames and more modern radio buttons and checkboxes. Together with a dark background and a bright text/foreground color, the style looks quite attractive (at least for Motif fans).
.PP
Note that the functions provided by QCDEStyle are reimplementations of QStyle functions; see QStyle for their documentation.
@ -49,7 +49,7 @@ If the last top-level window is closed, the QApplication::lastWindowClosed() sig
.PP
The isAccepted() function returns TRUE if the event's receiver has agreed to close the widget; call accept() to agree to close the widget and call ignore() if the receiver of this event does not want the widget to be closed.
.PP
See also QWidget::close(), QWidget::hide(), QObject::destroyed(), QApplication::setMainWidget(), QApplication::lastWindowClosed(), QApplication::exec(), QApplication::tquit(), and Event Classes.
See also QWidget::close(), QWidget::hide(), QObject::destroyed(), QApplication::setMainWidget(), QApplication::lastWindowClosed(), QApplication::exec(), QApplication::quit(), and Event Classes.
.SH MEMBER FUNCTION DOCUMENTATION
.SH "QCloseEvent::QCloseEvent ()"
Constructs a close event object with the accept parameter flag set to FALSE.
@ -185,7 +185,7 @@ Finally, there is a special role for text that needs to be drawn where Text or F
.TP
\fCQColorGroup::NColorRoles\fR - Internal.
.PP
Note that text colors can be used for things other than just words; text colors are \fIusually\fR used for text, but it's tquite common to use the text color roles for lines, icons, etc.
Note that text colors can be used for things other than just words; text colors are \fIusually\fR used for text, but it's quite common to use the text color roles for lines, icons, etc.
.PP
This image shows most of the color roles in use: <center>
@ -213,7 +213,7 @@ Closes the dialog and sets its result code to \fIr\fR. If this dialog is shown w
.PP
As with QWidget::close(), done() deletes the dialog if the WDestructiveClose flag is set. If the dialog is the application's main widget, the application terminates. If the dialog is the last window closed, the QApplication::lastWindowClosed() signal is emitted.
.PP
See also accept(), reject(), QApplication::mainWidget(), and QApplication::tquit().
See also accept(), reject(), QApplication::mainWidget(), and QApplication::quit().
.SH "int QDialog::exec ()\fC [slot]\fR"
Shows the dialog as a modal dialog, blocking until the user closes it. The function returns a DialogCode result.
@ -147,7 +147,7 @@ Generally speaking, no user interaction can take place before calling exec(). As
.PP
To make your application perform idle processing, i.e. executing a special function whenever there are no pending events, use a QTimer with 0 timeout. More advanced idle processing schemes can be achieved using processEvents().
.PP
See also QApplication::tquit(), exit(), and processEvents().
See also QApplication::quit(), exit(), and processEvents().
.SH "void QEventLoop::exit ( int retcode = 0 )\fC [virtual]\fR"
Tells the event loop to exit with a return code.
.PP
@ -157,7 +157,7 @@ By convention, a \fIretcode\fR of 0 means success, and any non-zero value indica
.PP
Note that unlike the C library function of the same name, this function \fIdoes\fR return to the caller -- it is event processing that stops.
@ -392,7 +392,7 @@ South and Southeast Asian scripts (left to right with few historical exceptions)
.TP
\fCQFont::Thai\fR - is used to write Thai and other Southeast Asian languages.
.TP
\fCQFont::Lao\fR - is a language and script tquite similar to Thai.
\fCQFont::Lao\fR - is a language and script quite similar to Thai.
.TP
\fCQFont::Tibetan\fR - is the script used to write Tibetan in several countries like Tibet, the bordering Indian regions and Nepal. It is also used in the Buddist philosophy and liturgy of the Mongolian cultural area.
\fBMac only\fR: This virtual function tries to find a visual that matches the format using the given \fIdevice\fR handle, reducing the demands if the original request cannot be met.
.PP
The algorithm for reducing the demands of the format is tquite simple-minded, so override this method in your subclass if your application has specific retquirements on visual selection.
The algorithm for reducing the demands of the format is quite simple-minded, so override this method in your subclass if your application has specific retquirements on visual selection.
\fBX11 only\fR: This virtual function tries to find a visual that matches the format, reducing the demands if the original request cannot be met.
.PP
The algorithm for reducing the demands of the format is tquite simple-minded, so override this method in your subclass if your application has spcific retquirements on visual selection.
The algorithm for reducing the demands of the format is quite simple-minded, so override this method in your subclass if your application has spcific retquirements on visual selection.
@ -33,7 +33,7 @@ In contrast to this, Unicode defines characters to be in logical order (the orde
.PP
Transformation from Unicode to visual Hebrew (8859-8) is done using the bidi algorithm in Qt, and will produce correct results, so long as the codec is given the text a whole paragraph at a time. Places where newlines are supposed to go can be indicated by a newline character ('\\n'). Note that these newline characters change the reordering behaviour of the algorithm, since the bidi reordering only takes place within one line of text, whereas line breaks are determined in visual order.
.PP
Visually ordered Hebrew is still used tquite often in some places, mainly in email communication (since most email programs still don't understand logically ordered Hebrew) and on web pages. The use on web pages is rapidly decreasing, due to the availability of browsers that correctly support logically ordered Hebrew.
Visually ordered Hebrew is still used quite often in some places, mainly in email communication (since most email programs still don't understand logically ordered Hebrew) and on web pages. The use on web pages is rapidly decreasing, due to the availability of browsers that correctly support logically ordered Hebrew.
.PP
This codec has the name "iso8859-8". If you don't want any bidi reordering to happen during conversion, use the "iso8859-8-i" codec, which assumes logical order for the 8-bit string.
@ -441,7 +441,7 @@ If the user does not select anything, no signals are emitted and currentItem() r
.PP
A list box has WheelFocus as a default focusPolicy(), i.e. it can get keyboard focus by tabbing, clicking and through the use of the mouse wheel.
.PP
New items can be inserted using insertItem(), insertStrList() or insertStringList(). inSort() is obsolete because this method is tquite inefficient. It's preferable to insert the items normally and call sort() afterwards, or to insert a sorted QStringList().
New items can be inserted using insertItem(), insertStrList() or insertStringList(). inSort() is obsolete because this method is quite inefficient. It's preferable to insert the items normally and call sort() afterwards, or to insert a sorted QStringList().
.PP
By default, vertical and horizontal scroll bars are added and removed as necessary. setHScrollBarMode() and setVScrollBarMode() can be used to change this policy.
.PP
@ -634,7 +634,7 @@ See also currentChanged(), selected(), currentItem, and selectionChanged().
@ -218,7 +218,7 @@ Qt/Mac also provides a menubar merging feature to make QMenuBar conform more clo
.PP
<center>.nf
.TS
l - l. String matches Placement Notes about.* Application Menu | About If this entry is not found no About item will appear in the Application Menu config, options, setup, settings or preferences Application Menu | Preferences If this entry is not found the Settings item will be disabled tquit or exit Application Menu | Quit If this entry is not found a default Quit item will be created to call
l - l. String matches Placement Notes about.* Application Menu | About If this entry is not found no About item will appear in the Application Menu config, options, setup, settings or preferences Application Menu | Preferences If this entry is not found the Settings item will be disabled quit or exit Application Menu | Quit If this entry is not found a default Quit item will be created to call
.TE
.fi
</center>
@ -282,7 +282,7 @@ A menu item is usually either a text string or a pixmap, both with an optional i
.PP
Some insertItem() members take a popup menu as an additional argument. Use this to insert submenus into existing menus or pulldown menus into a menu bar.
.PP
The number of insert functions may look confusing, but they are actually tquite simple to use.
The number of insert functions may look confusing, but they are actually quite simple to use.
.PP
This default version inserts a menu item with the text \fItext\fR, the accelerator key \fIaccel\fR, an id and an optional index and connects it to the slot \fImember\fR in the object \fIreceiver\fR.
@ -322,7 +322,7 @@ A menu item is usually either a text string or a pixmap, both with an optional i
.PP
Some insertItem() members take a popup menu as an additional argument. Use this to insert submenus into existing menus or pulldown menus into a menu bar.
.PP
The number of insert functions may look confusing, but they are actually tquite simple to use.
The number of insert functions may look confusing, but they are actually quite simple to use.
.PP
This default version inserts a menu item with the text \fItext\fR, the accelerator key \fIaccel\fR, an id and an optional index and connects it to the slot \fImember\fR in the object \fIreceiver\fR.
@ -226,7 +226,7 @@ Returns TRUE if auto-deleting is enabled; otherwise returns FALSE.
.PP
See also QNetworkProtocol::setAutoDelete().
.SH "bool QNetworkProtocol::checkConnection ( QNetworkOperation * op )\fC [virtual protected]\fR"
For processing operations the network protocol base class calls this method tquite often. This should be reimplemented by new network protocols. It should return TRUE if the connection is OK (open); otherwise it should return FALSE. If the connection is not open the protocol should open it.
For processing operations the network protocol base class calls this method quite often. This should be reimplemented by new network protocols. It should return TRUE if the connection is OK (open); otherwise it should return FALSE. If the connection is not open the protocol should open it.
.PP
If the connection can't be opened (e.g. because you already tried but the host couldn't be found), set the state of \fIop\fR to QNetworkProtocol::StFailed and emit the finished() signal with this QNetworkOperation as argument.
@ -779,7 +779,7 @@ Searches the children and optionally grandchildren of this object, and returns a
.PP
If \fIregexpMatch\fR is TRUE (the default), \fIobjName\fR is a regular expression that the objects's names must match. The syntax is that of a QRegExp. If \fIregexpMatch\fR is FALSE, \fIobjName\fR is a string and object names must match it exactly.
.PP
Note that \fIinheritsClass\fR uses single inheritance from QObject, the way inherits() does. According to inherits(), QMenuBar inherits QWidget but not QMenuData. This does not tquite match reality, but is the best that can be done on the wide variety of compilers Qt supports.
Note that \fIinheritsClass\fR uses single inheritance from QObject, the way inherits() does. According to inherits(), QMenuBar inherits QWidget but not QMenuData. This does not quite match reality, but is the best that can be done on the wide variety of compilers Qt supports.
.PP
Finally, if \fIrecursiveSearch\fR is TRUE (the default), queryList() searches \fIn\fRth-generation as well as first-generation children.
@ -410,7 +410,7 @@ A menu item is usually either a text string or a pixmap, both with an optional i
.PP
Some insertItem() members take a popup menu as an additional argument. Use this to insert submenus into existing menus or pulldown menus into a menu bar.
.PP
The number of insert functions may look confusing, but they are actually tquite simple to use.
The number of insert functions may look confusing, but they are actually quite simple to use.
.PP
This default version inserts a menu item with the text \fItext\fR, the accelerator key \fIaccel\fR, an id and an optional index and connects it to the slot \fImember\fR in the object \fIreceiver\fR.
Sets the queue to auto-delete its contents if \fIenable\fR is TRUE and not to delete them if \fIenable\fR is FALSE.
.PP
If auto-deleting is turned on, all the items in a queue are deleted when the queue itself is deleted. This can be tquite convenient if the queue has the only pointer to the items.
If auto-deleting is turned on, all the items in a queue are deleted when the queue itself is deleted. This can be quite convenient if the queue has the only pointer to the items.
.PP
The default setting is FALSE, for safety. If you turn it on, be careful about copying the queue: you might find yourself with two queues deleting the same items.
@ -309,7 +309,7 @@ Inherited by QCanvasView, QTable, QGridView, QIconView, QListBox, QListView, and
.SH DESCRIPTION
The QScrollView widget provides a scrolling area with on-demand scroll bars.
.PP
The QScrollView is a large canvas - potentially larger than the coordinate system normally supported by the underlying window system. This is important because it is tquite easy to go beyond these limitations (e.g. many web pages are more than 32000 pixels high). Additionally, the QScrollView can have QWidgets positioned on it that scroll around with the drawn content. These sub-widgets can also have positions outside the normal coordinate range (but they are still limited in size).
The QScrollView is a large canvas - potentially larger than the coordinate system normally supported by the underlying window system. This is important because it is quite easy to go beyond these limitations (e.g. many web pages are more than 32000 pixels high). Additionally, the QScrollView can have QWidgets positioned on it that scroll around with the drawn content. These sub-widgets can also have positions outside the normal coordinate range (but they are still limited in size).
.PP
To provide content for the widget, inherit from QScrollView, reimplement drawContents() and use resizeContents() to set the size of the viewed area. Use addChild() and moveChild() to position widgets on the view.
.PP
@ -757,7 +757,7 @@ Sets the resize policy. See the "resizePolicy" property for details.
.SH "void QScrollView::setStaticBackground ( bool y )"
Sets the scrollview to have a static background if \fIy\fR is TRUE, or a scrolling background if \fIy\fR is FALSE. By default, the background is scrolling.
.PP
Be aware that this mode is tquite slow, as a full repaint of the visible area has to be triggered on every contents move.
Be aware that this mode is quite slow, as a full repaint of the visible area has to be triggered on every contents move.
.PP
See also hasStaticBackground().
.SH "void QScrollView::setVBarGeometry ( QScrollBar & vbar, int x, int y, int w, int h )\fC [virtual protected]\fR"
@ -90,7 +90,7 @@ This enum type defines the circumstances under which this application wants to b
.TP
\fCQSessionManager::RestartIfRunning\fR - if the application is still running when the session is shut down, it wants to be restarted at the start of the next session.
.TP
\fCQSessionManager::RestartAnyway\fR - the application wants to be started at the start of the next session, no matter what. (This is useful for utilities that run just after startup and then tquit.)
\fCQSessionManager::RestartAnyway\fR - the application wants to be started at the start of the next session, no matter what. (This is useful for utilities that run just after startup and then quit.)
.TP
\fCQSessionManager::RestartImmediately\fR - the application wants to be started immediately whenever it is not running.
@ -165,7 +165,7 @@ The signals error(), connected(), readyRead() and connectionClosed() inform you
.PP
There are several access functions for the socket: state() returns whether the object is idle, is doing a DNS lookup, is connecting, has an operational connection, etc. address() and port() return the IP address and port used for the connection. The peerAddress() and peerPort() functions return the IP address and port used by the peer, and peerName() returns the name of the peer (normally the name that was passed to connectToHost()). socketDevice() returns a pointer to the QSocketDevice used for this socket.
.PP
QSocket inherits QIODevice, and reimplements some functions. In general, you can treat it as a QIODevice for writing, and mostly also for reading. The match isn't perfect, since the QIODevice API is designed for devices that are controlled by the same machine, and an asynchronous peer-to-peer network connection isn't tquite like that. For example, there is nothing that matches QIODevice::size() exactly. The documentation for open(), close(), flush(), size(), at(), atEnd(), readBlock(), writeBlock(), getch(), putch(), ungetch() and readLine() describes the differences in detail.
QSocket inherits QIODevice, and reimplements some functions. In general, you can treat it as a QIODevice for writing, and mostly also for reading. The match isn't perfect, since the QIODevice API is designed for devices that are controlled by the same machine, and an asynchronous peer-to-peer network connection isn't quite like that. For example, there is nothing that matches QIODevice::size() exactly. The documentation for open(), close(), flush(), size(), at(), atEnd(), readBlock(), writeBlock(), getch(), putch(), ungetch() and readLine() describes the differences in detail.
.PP
\fBWarning:\fR QSocket is not suitable for use in threads. If you need to uses sockets in threads use the lower-level QSocketDevice class.
@ -244,7 +244,7 @@ Returns TRUE if this is a valid socket; otherwise returns FALSE.
.PP
See also socket().
.SH "bool QSocketDevice::listen ( int backlog )\fC [virtual]\fR"
Specifies how many pending connections a server socket can have. Returns TRUE if the operation was successful; otherwise returns FALSE. A \fIbacklog\fR value of 50 is tquite common.
Specifies how many pending connections a server socket can have. Returns TRUE if the operation was successful; otherwise returns FALSE. A \fIbacklog\fR value of 50 is quite common.
.PP
The listen() call only applies to sockets where type() is Stream, i.e. not to Datagram sockets. listen() must not be called before bind() or after accept().
@ -1028,7 +1028,7 @@ Every widget's constructor accepts two or three standard arguments: <ol type=1>
.IP 1
\fCQWidget *parent = 0\fR is the parent of the new widget. If it is 0 (the default), the new widget will be a top-level window. If not, it will be a child of \fIparent\fR, and be constrained by \fIparent\fR's geometry (unless you specify WType_TopLevel as widget flag).
.IP 2
\fCconst char *name = 0\fR is the widget name of the new widget. You can access it using name(). The widget name is little used by programmers but is tquite useful with GUI builders such as \fIQt Designer\fR (you can name a widget in \fIQt Designer\fR, and connect() to it using the name in your code). The dumpObjectTree() debugging function also uses it.
\fCconst char *name = 0\fR is the widget name of the new widget. You can access it using name(). The widget name is little used by programmers but is quite useful with GUI builders such as \fIQt Designer\fR (you can name a widget in \fIQt Designer\fR, and connect() to it using the name in your code). The dumpObjectTree() debugging function also uses it.
.IP 3
\fCWFlags f = 0\fR (where available) sets the widget flags; the default is suitable for almost all widgets, but to get, for example, a top-level widget without a window system frame, you must use special flags.
.PP
@ -1049,7 +1049,7 @@ mousePressEvent() - called when a mouse button is pressed. There are six mouse-r
mouseReleaseEvent() - called when a mouse button is released. A widget receives mouse release events when it has received the corresponding mouse press event. This means that if the user presses the mouse inside \fIyour\fR widget, then drags the mouse to somewhere else, then releases, \fIyour\fR widget receives the release event. There is one exception: if a popup menu appears while the mouse button is held down, this popup immediately steals the mouse events.
.IP
.TP
mouseDoubleClickEvent() - not tquite as obvious as it might seem. If the user double-clicks, the widget receives a mouse press event (perhaps a mouse move event or two if they don't hold the mouse tquite steady), a mouse release event and finally this event. It is \fInot possible\fR to distinguish a click from a double click until you've seen whether the second click arrives. (This is one reason why most GUI books recommend that double clicks be an extension of single clicks, rather than trigger a different action.)
mouseDoubleClickEvent() - not quite as obvious as it might seem. If the user double-clicks, the widget receives a mouse press event (perhaps a mouse move event or two if they don't hold the mouse quite steady), a mouse release event and finally this event. It is \fInot possible\fR to distinguish a click from a double click until you've seen whether the second click arrives. (This is one reason why most GUI books recommend that double clicks be an extension of single clicks, rather than trigger a different action.)
.IP
.PP
If your widget only contains child widgets, you probably do not need to implement any event handlers. If you want to detect a mouse click in a child widget call the child's hasMouse() function inside the parent widget's mousePressEvent().
@ -1247,7 +1247,7 @@ The QApplication::lastWindowClosed() signal is emitted when the last visible top
.PP
Note that closing the QApplication::mainWidget() terminates the application.
.PP
See also closeEvent(), QCloseEvent, hide(), QApplication::tquit(), QApplication::setMainWidget(), and QApplication::lastWindowClosed().
See also closeEvent(), QCloseEvent, hide(), QApplication::quit(), QApplication::setMainWidget(), and QApplication::lastWindowClosed().
.SH "void QWidget::closeEvent ( QCloseEvent * e )\fC [virtual protected]\fR"
This event handler, for event \fIe\fR, can be reimplemented in a subclass to receive widget close events.
@ -77,7 +77,7 @@ Continues incremental parsing; this function reads the input from the QXmlInputS
.PP
Returns FALSE if a parsing error occurs; otherwise returns TRUE.
.PP
If the input source returns an empty string for the function QXmlInputSource::data(), then this means that the end of the XML file has been reached; this is tquite important, especially if you want to use the reader to parse more than one XML file.
If the input source returns an empty string for the function QXmlInputSource::data(), then this means that the end of the XML file has been reached; this is quite important, especially if you want to use the reader to parse more than one XML file.
.PP
The case of the end of the XML file being reached without having finished parsing is not considered to be an error: you can continue parsing at a later stage by calling this function again when there is more data available to parse.
Timothy Pearson
13 years ago