diff options
Diffstat (limited to 'doc/html/designer-manual-5.html')
| -rw-r--r-- | doc/html/designer-manual-5.html | 2 |
1 files changed, 1 insertions, 1 deletions
diff --git a/doc/html/designer-manual-5.html b/doc/html/designer-manual-5.html index 80cbf8da8..61b38dff4 100644 --- a/doc/html/designer-manual-5.html +++ b/doc/html/designer-manual-5.html @@ -66,7 +66,7 @@ body { background: #ffffff; color: black; } <p align="center"><img align="middle" src="designer1.jpg"> </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> <h4><a name="3-1"></a>The subclassing approach</h4> |