The widget is the atom of the user interface: it receives mouse, keyboard and other events from the window system, and paints a representation of itself on the screen. Every widget is rectangular, and they are sorted in a Z-order. A widget is clipped by its parent and by the widgets in front of it.
A widget that isn't embedded in a parent widget is called a top-level widget. Usually, top-level widgets are windows with a frame and a title bar (although it is also possible to create top-level widgets without such decoration if suitable widget flags are used). In Qt, TQMainWindow and the various subclasses of TQDialog are the most common top-level windows.
Non-top-level widgets are child widgets. These are child windows in their parent widgets. You cannot usually distinguish a child widget from its parent visually. Most other widgets in TQt are useful only as child widgets. (It is possible to make, say, a button into a top-level widget, but most people prefer to put their buttons inside other widgets, e.g. TQDialog.)
TQWidget has many member functions, but some of them have little direct functionality: for example, TQWidget has a font property, but never uses this itself. There are many subclasses which provide real functionality, such as TQPushButton, TQListBox and TQTabDialog, etc.
\fCTQWidget *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).
\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.
\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
The tictac/tictac.cpp example program is good example of a simple widget. It contains a few event handlers (as all widgets must), a few custom routines that are specific to it (as all useful widgets do), and has a few children and connections. Everything it does is done in response to an event: this is by far the most common way to design GUI applications.
.PP
You will need to supply the content for your widgets yourself, but here is a brief run-down of the events, starting with the most common ones:
.IP
.TP
paintEvent() - called whenever the widget needs to be repainted. Every widget which displays output must implement it, and it is wise \fInot\fR to paint on the screen outside paintEvent().
.IP
.TP
resizeEvent() - called when the widget has been resized.
.IP
.TP
mousePressEvent() - called when a mouse button is pressed. There are six mouse-related events, but the mouse press and mouse release events are by far the most important. A widget receives mouse press events when the mouse is inside it, or when it has grabbed the mouse using grabMouse().
.IP
.TP
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.
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.)
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().
.PP
Widgets that accept keyboard input need to reimplement a few more event handlers:
keyPressEvent() - called whenever a key is pressed, and again when a key has been held down long enough for it to auto-repeat. Note that the Tab and Shift+Tab keys are only passed to the widget if they are not used by the focus-change mechanisms. To force those keys to be processed by your widget, you must reimplement TQWidget::event().
focusInEvent() - called when the widget gains keyboard focus (assuming you have called setFocusPolicy()). Well written widgets indicate that they own the keyboard focus in a clear but discreet way.
.IP
.TP
focusOutEvent() - called when the widget loses keyboard focus.
.IP
.PP
Some widgets will also need to reimplement some of the less common event handlers:
.IP
.TP
mouseMoveEvent() - called whenever the mouse moves while a button is held down. This is useful for, for example, dragging. If you call setMouseTracking(TRUE), you get mouse move events even when no buttons are held down. (Note that applications which make use of mouse tracking are often not very useful on low-bandwidth X connections.) (See also the drag and drop information.)
keyReleaseEvent() - called whenever a key is released, and also while it is held down if the key is auto-repeating. In that case the widget receives a key release event and immediately a key press event for every repeat. Note that the Tab and Shift+Tab keys are only passed to the widget if they are not used by the focus-change mechanisms. To force those keys to be processed by your widget, you must reimplement TQWidget::event().
There are also some rather obscure events. They are listed in tqevent.h and you need to reimplement event() to handle them. The default implementation of event() handles Tab and Shift+Tab (to move the keyboard focus), and passes on most other events to one of the more specialized handlers above.
When implementing a widget, there are a few more things to consider.
.IP
.TP
In the constructor, be sure to set up your member variables early on, before there's any chance that you might receive an event.
.IP
.TP
It is almost always useful to reimplement sizeHint() and to set the correct size policy with setSizePolicy(), so users of your class can set up layout management more easily. A size policy lets you supply good defaults for the layout management handling, so that other widgets can contain and manage yours easily. sizeHint() indicates a "good" size for the widget.
.IP
.TP
If your widget is a top-level window, setCaption() and setIcon() set the title bar and icon respectively.
\fCTQWidget::StrongFocus\fR - the widget accepts focus by both tabbing and clicking. On Mac OS X this will also be indicate that the widget accepts tab focus when in 'Text/List focus mode'.
Constructs a widget which is a child of \fIparent\fR, with the name \fIname\fR and widget flags set to \fIf\fR.
.PP
If \fIparent\fR is 0, the new widget becomes a top-level window. If \fIparent\fR is another widget, this widget becomes a child window inside \fIparent\fR. The new widget is deleted when its \fIparent\fR is deleted.
The widget flags argument, \fIf\fR, is normally 0, but it can be set to customize the window frame of a top-level widget (i.e. \fIparent\fR must be 0). To customize the frame, set the WStyle_Customize flag OR'ed with any of the TQt::WidgetFlags.
Note that the X11 version of TQt may not be able to deliver all combinations of style flags on all systems. This is because on X11, TQt can only ask the window manager, and the window manager can override the application's settings. On Windows, TQt can set whatever flags you want.
Adjusts the size of the widget to fit the contents.
.PP
Uses sizeHint() if valid (i.e if the size hint's width and height are >= 0), otherwise sets the size to the children rectangle (the union of all child widget geometries).
\fBThis function is obsolete.\fR It is provided to keep old source working. We strongly advise against using it in new code. Use paletteBackgroundColor() or eraseColor() instead.
\fBThis function is obsolete.\fR It is provided to keep old source working. We strongly advise against using it in new code. Use paletteBackgroundPixmap() or erasePixmap() instead.
First it sends the widget a TQCloseEvent. The widget is hidden if it accepts the close event. The default implementation of TQWidget::closeEvent() accepts the close event.
If \fIalsoDelete\fR is TRUE or the widget has the WDestructiveClose widget flag, the widget is also deleted. The widget can prevent itself from being closed by rejecting the TQCloseEvent it gets. A close events is delivered to the widget no matter if the widget is visible or not.
Creates a new widget window if \fIwindow\fR is 0, otherwise sets the widget's window to \fIwindow\fR.
.PP
Initializes the window (sets the geometry etc.) if \fIinitializeWindow\fR is TRUE. If \fIinitializeWindow\fR is FALSE, no initialization is performed. This parameter only makes sense if \fIwindow\fR is a valid window.
.PP
Destroys the old window if \fIdestroyOldWindow\fR is TRUE. If \fIdestroyOldWindow\fR is FALSE, you are responsible for destroying the window yourself (using platform native code).
Frees up window system resources. Destroys the widget window if \fIdestroyWindow\fR is TRUE.
.PP
destroy() calls itself recursively for all the child widgets, passing \fIdestroySubWindows\fR for the \fIdestroyWindow\fR parameter. To have more control over destruction of subwidgets, destroy subwidgets selectively first.
This virtual function is called from setEnabled(). \fIoldEnabled\fR is the previous setting; you can get the new setting from isEnabled().
.PP
Reimplement this function if your widget needs to know when it becomes enabled or disabled. You will almost certainly need to update the widget using update().
.PP
The default implementation repaints the visible part of the widget.
.PP
See also enabled, enabled, repaint(), update(), and clipRegion().
This is the main event handler; it handles event \fIe\fR. You can reimplement this function in a subclass, but we recommend using one of the specialized event handlers instead.
.PP
The main event handler first passes an event through all event filters that have been installed. If none of the filters intercept the event, it calls one of the specialized event handlers.
.PP
Key press and release events are treated differently from other events. event() checks for Tab and Shift+Tab and tries to move the focus appropriately. If there is no widget to move the focus to (or the key press is not Tab or Shift+Tab), event() calls keyPressEvent().
.PP
This function returns TRUE if it is able to pass the event over to someone (i.e. someone wanted the event); otherwise returns FALSE.
The window identifier type depends on the underlying window system, see tqwindowdefs.h for the actual definition. If there is no widget with this identifier, 0 is returned.
Returns the focus data for this widget's top-level widget.
.PP
Focus data always belongs to the top-level widget. The focus data list contains all the widgets in this top-level widget that can accept focus, in tab order. An iterator points to the current focus widget (focusWidget() returns a pointer to this widget).
.PP
This information is useful for implementing advanced versions of focusNextPrevChild().
This event handler can be reimplemented in a subclass to receive keyboard focus events (focus received) for the widget.
.PP
A widget normally must setFocusPolicy() to something other than NoFocus in order to receive focus events. (Note that the application programmer can call setFocus() on any widget, even those that do not normally accept focus.)
.PP
The default implementation updates the widget (except for toplevel widgets that do not specify a focusPolicy() ). It also calls setMicroFocusHint(), hinting any system-specific input tools about the focus of the user's attention.
Finds a new widget to give the keyboard focus to, as appropriate for Tab and Shift+Tab, and returns TRUE if is can find a new widget and FALSE if it can't,
.PP
If \fInext\fR is TRUE, this function searches "forwards", if \fInext\fR is FALSE, it searches "backwards".
Sometimes, you will want to reimplement this function. For example, a web browser might reimplement it to move its "current active link" forwards or backwards, and call TQWidget::focusNextPrevChild() only when it reaches the last or first link on the "page".
Child widgets call focusNextPrevChild() on their parent widgets, but only the top-level widget decides where to redirect focus. By overriding this method for an object, you thus gain control of focus traversal for all child widgets.
\fBWarning:\fR TQScrollView uses it own logic for this function, which does the right thing in most cases. But if you are using a TQScrollView and want complete control of the focus chain you'll need to override TQScrollView::focusNextPrevChild() and your top-level widgets' focusNextPrevChild() functions.
This event handler can be reimplemented in a subclass to receive keyboard focus events (focus lost) for the widget.
.PP
A widget normally must setFocusPolicy() to something other than NoFocus in order to receive focus events. (Note that the application programmer can call setFocus() on any widget, even those that do not normally accept focus.)
.PP
The default implementation updates the widget (except for toplevel widgets that do not specify a focusPolicy() ). It also calls setMicroFocusHint(), hinting any system-specific input tools about the focus of the user's attention.
Returns the focus widget in this widget's window. This is not the same as TQApplication::focusWidget(), which returns the focus widget in the currently active window.
This widget reveives all keyboard events until releaseKeyboard() is called; other widgets get no keyboard events at all. Mouse events are not affected. Use grabMouse() if you want to grab that.
.PP
The focus widget is not affected, except that it doesn't receive any keyboard events. setFocus() moves the focus as usual, but the new focus widget receives keyboard events only after releaseKeyboard() is called.
.PP
If a different widget is currently grabbing keyboard input, that widget's grab is released first.
.PP
See also releaseKeyboard(), grabMouse(), releaseMouse(), and focusWidget().
This widget receives all mouse events until releaseMouse() is called; other widgets get no mouse events at all. Keyboard events are not affected. Use grabKeyboard() if you want to grab that.
.PP
\fBWarning:\fR Bugs in mouse-grabbing applications very often lock the terminal. Use this function with extreme caution, and consider using the \fC-nograb\fR command line option while debugging.
It is almost never necessary to grab the mouse when using Qt, as TQt grabs and releases it sensibly. In particular, TQt grabs the mouse when a mouse button is pressed and keeps it until the last button is released.
This is an overloaded member function, provided for convenience. It behaves essentially like the above function.
.PP
Grabs the mouse input and changes the cursor shape.
.PP
The cursor will assume shape \fIcursor\fR (for as long as the mouse focus is grabbed) and this widget will be the only one to receive mouse events until releaseMouse() is called().
.PP
\fBWarning:\fR Grabbing the mouse might lock the terminal.
.PP
See also releaseMouse(), grabKeyboard(), releaseKeyboard(), and cursor.
Returns the preferred height for this widget, given the width \fIw\fR. The default implementation returns 0, indicating that the preferred height does not depend on the width.
.PP
\fBWarning:\fR Does not look at the widget's layout.
This event handler, for event \fIe\fR, can be reimplemented in a subclass to receive Input Method composition events. This handler is called when the user has entered some text using an Input Method.
This event handler, for event \fIe\fR, can be reimplemented in a subclass to receive Input Method composition events. This handler is called when the user has finished inputting text via an Input Method.
This event handler, for event \fIe\fR, can be reimplemented in a subclass to receive Input Method composition events. This handler is called when the user begins entering text using an Input Method.
Returns TRUE if this widget would become visible if \fIancestor\fR is shown; otherwise returns FALSE.
.PP
The TRUE case occurs if neither the widget itself nor any parent up to but excluding \fIancestor\fR has been explicitly hidden.
.PP
This function will still return TRUE if the widget is obscured by other windows on the screen, but could be physically visible if it or they were to be moved.
This event handler, for event \fIe\fR, can be reimplemented in a subclass to receive key press events for the widget.
.PP
A widget must call setFocusPolicy() to accept focus initially and have focus in order to receive a key press event.
.PP
If you reimplement this handler, it is very important that you explicitly ignore the event if you do not understand it, so that the widget's parent can interpret it; otherwise, the event will be implicitly accepted. Although top-level widgets are able to choose whether to accept or ignore unknown events because they have no parent widgets that could otherwise handle them, it is good practice to explicitly ignore events to make widgets as reusable as possible.
.PP
The default implementation closes popup widgets if the user presses \fBEsc\fR. Otherwise the event is ignored.
This event handler, for event \fIe\fR, can be reimplemented in a subclass to receive key release events for the widget.
.PP
A widget must accept focus initially and have focus in order to receive a key release event.
.PP
If you reimplement this handler, it is very important that you ignore() the release if you do not understand it, so that the widget's parent can interpret it.
In your reimplementation of this function, if you want to stop the event being handled by Qt, return TRUE. If you return FALSE, this native event is passed back to Qt, which translates the event into a TQt event and sends it to the widget.
Translates the widget coordinate \fIpos\fR from the coordinate system of \fIparent\fR to this widget's coordinate system. The \fIparent\fR must not be 0 and must be a parent of the calling widget.
.PP
See also mapTo(), mapFromParent(), mapFromGlobal(), and underMouse.
Translates the widget coordinate \fIpos\fR to the coordinate system of \fIparent\fR. The \fIparent\fR must not be 0 and must be a parent of the calling widget.
.PP
See also mapFrom(), mapToParent(), mapToGlobal(), and underMouse.
Translates the widget coordinate \fIpos\fR to global screen coordinates. For example, \fCmapToGlobal(TQPoint(0,0))\fR would give the global coordinates of the top-left pixel of the widget.
This event handler, for event \fIe\fR, can be reimplemented in a subclass to receive mouse move events for the widget.
.PP
If mouse tracking is switched off, mouse move events only occur if a mouse button is pressed while the mouse is being moved. If mouse tracking is switched on, mouse move events occur even if no mouse button is pressed.
TQMouseEvent::pos() reports the position of the mouse cursor, relative to this widget. For press and release events, the position is usually the same as the position of the last mouse move event, but it might be different if the user's hand shakes. This is a feature of the underlying window system, not Qt.
This event handler, for event \fIe\fR, can be reimplemented in a subclass to receive mouse press events for the widget.
.PP
If you create new widgets in the mousePressEvent() the mouseReleaseEvent() may not end up where you expect, depending on the underlying window system (or X11 window manager), the widgets' location and maybe more.
.PP
The default implementation implements the closing of popup widgets when you click outside the window. For other widget types it does nothing.
This event handler can be reimplemented in a subclass to receive widget move events. When the widget receives this event, it is already at the new position.
This event handler can be reimplemented in a subclass to receive paint events.
.PP
A paint event is a request to repaint all or part of the widget. It can happen as a result of repaint() or update(), or because the widget was obscured and has now been uncovered, or for many other reasons.
Many widgets can simply repaint their entire surface when asked to, but some slow widgets need to optimize by painting only the requested region: TQPaintEvent::region(). This speed optimization does not change the result, as painting is clipped to that region during event processing. TQListView and TQCanvas do this, for example.
Qt also tries to speed up painting by merging multiple paint events into one. When update() is called several times or the window system sends several paint events, TQt merges these events into one event with a larger region (see TQRegion::unite()). repaint() does not permit this optimization, so we suggest using update() when possible.
When the paint event occurs, the update region has normally been erased, so that you're painting on the widget's background. There are a couple of exceptions and TQPaintEvent::erased() tells you whether the widget has been erased or not.
The background can be set using setBackgroundMode(), setPaletteBackgroundColor() or setBackgroundPixmap(). The documentation for setBackgroundMode() elaborates on the background; we recommend reading it.
Returns the parent of this widget, or 0 if it does not have any parent widget. If \fIsameWindow\fR is TRUE and the widget is top level returns 0; otherwise returns the widget's parent.
This function will be called \fIafter\fR a widget has been fully created and \fIbefore\fR it is shown the very first time.
.PP
Polishing is useful for final initialization which depends on having an instantiated widget. This is something a constructor cannot guarantee since the initialization of the subclasses might not be finished.
We suggest only using repaint() if you need an immediate repaint, for example during animation. In almost all circumstances update() is better, as it permits TQt to optimize for speed and minimize flicker.
\fBWarning:\fR If you call repaint() in a function which may itself be called from paintEvent(), you may get infinite recursion. The update() function never causes recursion.
.PP
See also update(), paintEvent(), updatesEnabled, and erase().
This is an overloaded member function, provided for convenience. It behaves essentially like the above function.
.PP
Repaints the widget directly by calling paintEvent() directly, unless updates are disabled or the widget is hidden.
.PP
Erases the widget region \fIreg\fR if \fIerase\fR is TRUE.
.PP
Only use repaint if your widget needs to be repainted immediately, for example when doing some animation. In all other cases, use update(). Calling update() many times in a row will generate a single paint event.
.PP
\fBWarning:\fR If you call repaint() in a function which may itself be called from paintEvent(), you may get infinite recursion. The update() function never causes recursion.
.PP
See also update(), paintEvent(), updatesEnabled, and erase().
Reparents the widget. The widget gets a new \fIparent\fR, new widget flags (\fIf\fR, but as usual, use 0) at a new position in its new parent (\fIp\fR).
.PP
If \fIshowIt\fR is TRUE, show() is called once the widget has been reparented.
.PP
If the new parent widget is in a different top-level widget, the reparented widget and its children are appended to the end of the tab chain of the new parent widget, in the same internal order as before. If one of the moved widgets had keyboard focus, reparent() calls clearFocus() for that widget.
.PP
If the new parent widget is in the same top-level widget as the old parent, reparent doesn't change the tab order or keyboard focus.
\fBWarning:\fR It is extremely unlikely that you will ever need this function. If you have a widget that changes its content dynamically, it is far easier to use TQWidgetStack or TQWizard.
This event handler can be reimplemented in a subclass to receive widget resize events. When resizeEvent() is called, the widget already has its new geometry. The old size is accessible through TQResizeEvent::oldSize().
The widget will be erased and receive a paint event immediately after processing the resize event. No drawing need be (or should be) done inside this handler.
.PP
Widgets that have been created with the WNoAutoErase flag will not be erased. Nevertheless, they will receive a paint event for their entire area afterwards. Again, no drawing needs to be done inside this handler.
.PP
The default implementation calls updateMask() if the widget has automatic masking enabled.
After scrolling, scroll() sends a paint event for the the part that is read but not written. For example, when scrolling 10 pixels rightwards, the leftmost ten pixels of the widget need repainting. The paint event may be delivered immediately or later, depending on some heuristics (note that you might have to force processing of paint events using TQApplication::sendPostedEvents() when using scroll() and move() in combination).
Sets the top-level widget containing this widget to be the active window.
.PP
An active window is a visible top-level window that has the keyboard input focus.
.PP
This function performs the same operation as clicking the mouse on the title bar of a top-level window. On X11, the result depends on the Window Manager. If you want to ensure that the window is stacked on top as well you should also call raise(). Note that the window must be visible, otherwise setActiveWindow() has no effect.
.PP
On Windows, if you are calling this when the application is not currently the active one then it will not make it the active window. It will flash the task bar entry blue to indicate that the window has done something. This is because Microsoft do not allow an application to interrupt what the user is currently doing in another application.
.PP
See also isActiveWindow, topLevelWidget(), and show().
\fBThis function is obsolete.\fR It is provided to keep old source working. We strongly advise against using it in new code. Use setPaletteBackgroundColor() or setEraseColor() instead.
.PP
Examples:
.)l customlayout/main.cpp, desktop/desktop.cpp, hello/main.cpp, movies/main.cpp, and splitter/splitter.cpp.
This is an overloaded member function, provided for convenience. It behaves essentially like the above function.
.PP
Sets the widget's own background mode to \fIm\fR and the visual background mode to \fIvisual\fR. The visual background mode is used with the designable properties \fCbackgroundColor\fR, \fCforegroundColor\fR and \fCbackgroundPixmap\fR.
.PP
For complex controls, the logical background mode sometimes differs from a widget's own background mode. A spinbox for example has PaletteBackground as background mode (typically dark gray), while it's embedded lineedit control uses PaletteBase (typically white). Since the lineedit covers most of the visual area of a spinbox, it defines PaletteBase to be its \fIvisual\fR background mode. Changing the \fCbackgroundColor\fR property thus changes the lineedit control's background, which is exactly what the user expects in \fIQt Designer\fR.
\fBThis function is obsolete.\fR It is provided to keep old source working. We strongly advise against using it in new code. Use setPaletteBackgroundPixmap() or setErasePixmap() instead.
Sets the erase color of the widget to \fIcolor\fR.
.PP
The erase color is the color the widget is to be cleared to before paintEvent() is called. If there is an erase pixmap (set using setErasePixmap()), then this property has an indeterminate value.
.PP
See also erasePixmap(), backgroundColor(), backgroundMode, and palette.
Gives the keyboard input focus to this widget (or its focus proxy) if this widget or one of its parents is the active window.
.PP
First, a focus out event is sent to the focus widget (if any) to tell it that it is about to lose the focus. Then a focus in event is sent to this widget to tell it that it just received the focus. (Nothing happens if the focus in and focus out widgets are the same.)
.PP
setFocus() gives focus to a widget regardless of its focus policy, but does not clear any keyboard grab (see grabKeyboard()).
.PP
Be aware that if the widget is hidden, it will not accept focus.
.PP
\fBWarning:\fR If you call setFocus() in a function which may itself be called from focusOutEvent() or focusInEvent(), you may get an infinite recursion.
Some widgets, such as TQComboBox, can "have focus", but create a child widget to actually handle the focus. TQComboBox, for example, creates a TQLineEdit which handles the focus.
setFocusProxy() sets the widget which will actually get focus when" this widget" gets it. If there is a focus proxy, focusPolicy(), setFocusPolicy(), setFocus() and hasFocus() all operate on the focus proxy.
Key compression is off by default (except for TQLineEdit and TQTextEdit), so widgets receive one key press event for each key press (or more, since autorepeat is usually on). If you turn it on and your program doesn't keep up with key input, TQt may try to compress key events so that more than one character can be processed in each event.
For example, a word processor widget might receive 2, 3 or more characters in each TQKeyEvent::text(), if the layout recalculation takes too long for the CPU.
If a widget supports multiple character unicode input, it is always safe to turn the compression on.
.PP
Qt performs key event compression only for printable characters. Modifier keys, cursor movement keys, function keys and miscellaneous action keys (e.g. Escape, Enter, Backspace, PrintScreen) will stop key event compression, even if there are more compressible key events available.
.PP
Not all platforms support this compression, in which case turning it on will have no effect.
Causes only the pixels of the widget for which \fIbitmap\fR has a corresponding 1 bit to be visible. Use TQt::color0 to draw transparent regions and TQt::color1 to draw opaque regions of the bitmap.
If the region includes pixels outside the rect() of the widget, window system controls in that area may or may not be visible, depending on the platform.
.PP
Note that this effect can be slow if the region is particularly complex.
.PP
See \fCexamples/tux\fR for an example of masking for transparency.
This is an overloaded member function, provided for convenience. It behaves essentially like the above function.
.PP
Causes only the parts of the widget which overlap \fIregion\fR to be visible. If the region includes pixels outside the rect() of the widget, window system controls in that area may or may not be visible, depending on the platform.
.PP
Note that this effect can be slow if the region is particularly complex.
This function corresponds to setMaximumSize( TQSize(\fImaxw\fR, \fImaxh\fR) ). Sets the maximum width to \fImaxw\fR and the maximum height to \fImaxh\fR.
When a widget gets focus, it should call setMicroFocusHint() with some appropriate position and size, \fIx\fR, \fIy\fR, \fIwidth\fR and \fIheight\fR. This has no \fIvisual\fR effect, it just provides hints to any system-specific input handling tools.
.PP
The \fItext\fR argument should be TRUE if this is a position for text input.
.PP
In the Windows version of Qt, this method sets the system caret, which is used for user Accessibility focus handling. If \fItext\fR is TRUE, it also sets the IME composition window in Far East Asian language input systems.
.PP
In the X11 version of Qt, if \fItext\fR is TRUE, this method sets the XIM "spot" point for complex language input handling.
.PP
The font \fIf\fR is a rendering hint to the currently active input method. If \fIf\fR is 0 the widget's font is used.
Setting a widget's style has no effect on existing or future child widgets.
.PP
\fBWarning:\fR This function is particularly useful for demonstration purposes, where you want to show Qt's styling capabilities. Real applications should avoid it and use one consistent GUI style instead.
Moves the \fIsecond\fR widget around the ring of focus widgets so that keyboard focus moves from the \fIfirst\fR widget to the \fIsecond\fR widget when the Tab key is pressed.
.PP
Note that since the tab order of the \fIsecond\fR widget is changed, you should order a chain like this:
.PP
.nf
.br
setTabOrder( a, b ); // a to b
.br
setTabOrder( b, c ); // a to b to c
.br
setTabOrder( c, d ); // a to b to c to d
.br
.fi
.PP
\fInot\fR like this:
.PP
.nf
.br
setTabOrder( c, d ); // c to d WRONG
.br
setTabOrder( a, b ); // a to b AND c to d
.br
setTabOrder( b, c ); // a to b to c, but not c to d
.br
.fi
.PP
If \fIfirst\fR or \fIsecond\fR has a focus proxy, setTabOrder() correctly substitutes the proxy.
Sets the window state to \fIwindowState\fR. The window state is a OR'ed combination of TQt::WindowState: WindowMinimized, WindowMaximized, WindowFullScreen and WindowActive.
If the window is not visible (i.e. isVisible() returns FALSE), the window state will take effect when show() is called. For visible windows, the change is immediate. For example, to toggle between full-screen and mormal mode, use the following code:
You almost never have to reimplement this function. If you need to change some settings before a widget is shown, use showEvent() instead. If you need to do some delayed initialization use polish().
.PP
See also showEvent(), hide(), showMinimized(), showMaximized(), showNormal(), visible, and polish().
.PP
Examples:
.)l aclock/main.cpp, life/main.cpp, popup/popup.cpp, t1/main.cpp, t3/main.cpp, t4/main.cpp, and toplevel/options.ui.h.
This event handler can be reimplemented in a subclass to receive widget show events.
.PP
Non-spontaneous show events are sent to widgets immediately before they are shown. The spontaneous show events of top-level widgets are delivered afterwards.
Calling this function only affects top-level widgets.
.PP
To return from full-screen mode, call showNormal().
.PP
Full-screen mode works fine under Windows, but has certain problems under X. These problems are due to limitations of the ICCCM protocol that specifies the communication between X11 clients and the window manager. ICCCM simply does not understand the concept of non-decorated full-screen windows. Therefore, the best we can do is to request a borderless window and place and resize it to fill the entire screen. Depending on the window manager, this may or may not work. The borderless window is requested using MOTIF hints, which are at least partially supported by virtually all modern window managers.
.PP
An alternative would be to bypass the window manager entirely and create a window with the WX11BypassWM flag. This has other severe problems though, like totally broken keyboard focus and very strange effects on desktop changes or when the user raises other windows.
.PP
X11 window managers that follow modern post-ICCCM specifications support full-screen mode properly.
.PP
See also showNormal(), showMaximized(), show(), hide(), and visible.
This virtual function is called when the style of the widgets changes. \fIoldStyle\fR is the previous GUI style; you can get the new style from style().
.PP
Reimplement this function if your widget needs to know when its GUI style changes. You will almost certainly need to update the widget using update().
.PP
The default implementation updates the widget including its geometry.
This event handler, for event \fIe\fR, can be reimplemented in a subclass to receive tablet events for the widget.
.PP
If you reimplement this handler, it is very important that you ignore() the event if you do not handle it, so that the widget's parent can interpret it.
If you want to test for the presence of multiple flags (or composite flags such as WStyle_Splash), test the return value for equality against the argument. For example:
.PP
.nf
.br
int flags = WStyle_Tool | WStyle_NoBorder;
.br
if ( testWFlags(flags) )
.br
... // WStyle_Tool or WStyle_NoBorder or both are set
.br
if ( testWFlags(flags) == flags )
.br
... // both WStyle_Tool and WStyle_NoBorder are set
.br
.fi
.PP
See also getWFlags(), setWFlags(), and clearWFlags().
This function does not cause an immediate repaint; instead it schedules a paint event for processing when TQt returns to the main event loop. This permits TQt to optimize for more speed and less flicker than a call to repaint() does.
Calling update() several times normally results in just one paintEvent() call.
.PP
Qt normally erases the widget's area before the paintEvent() call. If the WRepaintNoErase widget flag is set, the widget is responsible for painting all its pixels itself.
.PP
See also repaint(), paintEvent(), updatesEnabled, erase(), and setWFlags().
.PP
Examples:
.)l desktop/desktop.cpp and scrollview/scrollview.cpp.
This function does not cause an immediate repaint; instead it schedules a paint event for processing when TQt returns to the main event loop. This permits TQt to optimize for more speed and less flicker and a call to repaint() does.
Calling update() several times normally results in just one paintEvent() call.
.PP
If \fIw\fR is negative, it is replaced with \fCwidth() - x\fR. If \fIh\fR is negative, it is replaced width \fCheight() - y\fR.
.PP
Qt normally erases the specified area before the paintEvent() call. If the WRepaintNoErase widget flag is set, the widget is responsible for painting all its pixels itself.
.PP
See also repaint(), paintEvent(), updatesEnabled, and erase().
This function does not cause an immediate repaint; instead it schedules a paint event for processing when TQt returns to the main event loop. This permits TQt to optimize for more speed and less flicker and a call to repaint() does.
This function can be reimplemented in a subclass to support transparent widgets. It should be called whenever a widget changes state in a way that means that the shape mask must be recalculated.
This event handler, for event \fIe\fR, can be reimplemented in a subclass to receive wheel events for the widget.
.PP
If you reimplement this handler, it is very important that you ignore() the event if you do not handle it, so that the widget's parent can interpret it.
.PP
The default implementation ignores the event.
.PP
See also QWheelEvent::ignore(), QWheelEvent::accept(), event(), and QWheelEvent.
In your reimplementation of this function, if you want to stop the event being handled by Qt, return TRUE. If you return FALSE, this native event is passed back to Qt, which translates the event into a TQt event and sends it to the widget.
This virtual function is called for a widget when its window is activated or deactivated by the window system. \fIoldActive\fR is the previous state; you can get the new setting from isActiveWindow().
.PP
Reimplement this function if your widget needs to know when its window becomes activated or deactivated.
.PP
The default implementation updates the visible part of the widget if the inactive and the active colorgroup are different for colors other than the highlight and link colors.
.PP
See also setActiveWindow(), isActiveWindow, update(), and palette.
Returns the current window state. The window state is a OR'ed combination of TQt::WindowState: WindowMinimized, WindowMaximized, WindowFullScreen and WindowActive.
In your reimplementation of this function, if you want to stop the event being handled by Qt, return TRUE. If you return FALSE, this native event is passed back to Qt, which translates the event into a TQt event and sends it to the widget.
If the widget is the desktop (TQWidget::isDesktop()), this may fail if another application is using the desktop; you can call acceptDrops() to test if this occurs.
Transparent widgets use a mask to define their visible region. TQWidget has some built-in support to make the task of recalculating the mask easier. When setting auto mask to TRUE, updateMask() will be called whenever the widget is resized or changes its focus state. Note that you must reimplement updateMask() (which should include a call to setMask()) or nothing will happen.
Note: when you re-implement resizeEvent(), focusInEvent() or focusOutEvent() in your custom widgets and still want to ensure that the auto mask calculation works, you should add:
at the end of your event handlers. This is true for all member functions that change the appearance of the widget in a way that requires a recalculation of the mask.
While being a technically appealing concept, masks have a big drawback: when using complex masks that cannot be expressed easily with relatively simple regions, they can be very slow on some window systems. The classic example is a transparent label. The complex shape of its contents makes it necessary to represent its mask by a bitmap, which consumes both memory and time. If all you want is to blend the background of several neighboring widgets together seamlessly, you will probably want to use setBackgroundOrigin() rather than a mask.
.PP
See also updateMask(), setMask(), clearMask(), and backgroundOrigin.
.PP
Set this property's value with setAutoMask() and get this property's value with autoMask().
This property holds the color role used for painting the background of the widget.
.PP
setPaletteBackgroundColor() reads this property to determine which entry of the palette to set.
.PP
For most widgets the default suffices (PaletteBackground, typically gray), but some need to use PaletteBase (the background color for text output, typically white) or another role.
You will never need to set the background mode of a built-in widget in Qt, but you might consider setting it in your custom widgets, so that setPaletteBackgroundColor() works as expected.
.PP
Note that two of the BackgroundMode values make no sense for setBackgroundMode(), namely FixedPixmap and FixedColor. You must call setBackgroundPixmap() and setPaletteBackgroundColor() instead.
.PP
Set this property's value with setBackgroundMode() and get this property's value with backgroundMode().
.SH "BackgroundOrigin backgroundOrigin"
This property holds the origin of the widget's background.
.PP
The origin is either WidgetOrigin (the default), ParentOrigin, WindowOrigin or AncestorOrigin.
.PP
This only makes a difference if the widget has a background pixmap, in which case positioning matters. Using WindowOrigin for several neighboring widgets makes the background blend together seamlessly. AncestorOrigin allows blending backgrounds seamlessly when an ancestor of the widget has an origin other than WindowOrigin.
.PP
See also backgroundPixmap() and backgroundMode.
.PP
Set this property's value with setBackgroundOrigin() and get this property's value with backgroundOrigin().
The color group is determined by the state of the widget. A disabled widget has the TQPalette::disabled() color group, a widget with keyboard focus has the TQPalette::active() color group, and an inactive widget has the TQPalette::inactive() color group.
This property holds the cursor shape for this widget.
.PP
The mouse cursor will assume this shape when it's over this widget. See the list of predefined cursor objects for a range of useful shapes.
.PP
An editor widget might use an I-beam cursor:
.PP
.nf
.br
setCursor( IbeamCursor );
.br
.fi
.PP
If no cursor has been set, or after a call to unsetCursor(), the parent's cursor is used. The function unsetCursor() has no effect on top-level widgets.
You can also reimplement customWhatsThis() if your widget is a" passive interactor" supposed to work under all circumstances. Simply don't call TQWhatsThis::leaveWhatsThisMode() in that case.
This property holds whether the widget is enabled.
.PP
An enabled widget receives keyboard and mouse events; a disabled widget does not. In fact, an enabled widget only receives keyboard events when it is in focus.
.PP
Some widgets display themselves differently when they are disabled. For example a button might draw its label grayed out. If your widget needs to know when it becomes enabled or disabled, you can reimplement the enabledChange() function.
.PP
Disabling a widget implicitly disables all its children. Enabling respectively enables all child widgets unless they have been explicitly disabled.
You must enable keyboard focus for a widget if it processes keyboard events. This is normally done from the widget's constructor. For instance, the TQLineEdit constructor calls setFocusPolicy(TQWidget::StrongFocus).
The policy is TQWidget::TabFocus if the widget accepts keyboard focus by tabbing, TQWidget::ClickFocus if the widget accepts focus by clicking, TQWidget::StrongFocus if it accepts both, and TQWidget::NoFocus (the default) if it does not accept focus at all.
You must enable keyboard focus for a widget if it processes keyboard events. This is normally done from the widget's constructor. For instance, the TQLineEdit constructor calls setFocusPolicy(TQWidget::StrongFocus).
This property holds the font currently set for the widget.
.PP
The fontInfo() function reports the actual font that is being used by the widget.
.PP
As long as no special font has been set, or after unsetFont() is called, this is either a special font for the widget class, the parent's font or (if this widget is a top level widget), the default application font.
.PP
This code fragment sets a 12 point helvetica bold font:
This property holds the geometry of the widget relative to its parent and excluding the window frame.
.PP
When changing the geometry, the widget, if visible, receives a move event (moveEvent()) and/or a resize event (resizeEvent()) immediately. If the widget is not currently visible, it is guaranteed to receive appropriate events before it is shown.
.PP
The size component is adjusted if it lies outside the range defined by minimumSize() and maximumSize().
This property holds whether the widget is a popup widget.
.PP
A popup widget is created by specifying the widget flag WType_Popup to the widget constructor. A popup widget is also a top-level widget.
.PP
See also isTopLevel.
.PP
Get this property's value with isPopup().
.SH "bool isTopLevel"
This property holds whether the widget is a top-level widget.
.PP
A top-level widget is a widget which usually has a frame and a caption (title). Popup and desktop widgets are also top-level widgets.
.PP
A top-level widget can have a parent widget. It will then be grouped with its parent and deleted when the parent is deleted, minimized when the parent is minimized etc. If supported by the window manager, it will also have a common taskbar entry with its parent.
TQDialog and TQMainWindow widgets are by default top-level, even if a parent widget is specified in the constructor. This behavior is specified by the WType_TopLevel widget flag.
Note that due to limitations in some window-systems, this does not always report the expected results (e.g. if the user on X11 maximizes the window via the window manager, TQt has no way of distinguishing this from any other resize). This is expected to improve as window manager protocols evolve.
The widget cannot be resized to a smaller size than the minimum widget size. The widget's size is forced to the minimum size if the current size is smaller.
If you use a layout inside the widget, the minimum size will be set by the layout and not by setMinimumSize(), unless you set the layout's resize mode to TQLayout::FreeResize.
This property holds the recommended minimum size for the widget.
.PP
If the value of this property is an invalid size, no minimum size is recommended.
.PP
The default implementation of minimumSizeHint() returns an invalid size if there is no layout for this widget, and returns the layout's minimum size otherwise. Most built-in widgets reimplement minimumSizeHint().
This property corresponds to minimumSize().width().
.PP
See also minimumSize and minimumHeight.
.PP
Set this property's value with setMinimumWidth() and get this property's value with minimumWidth().
.SH "bool mouseTracking"
This property holds whether mouse tracking is enabled for the widget.
.PP
If mouse tracking is disabled (the default), the widget only receives mouse move events when at least one mouse button is pressed while the mouse is being moved.
.PP
If mouse tracking is enabled, the widget receives mouse move events even if no buttons are pressed.
As long as no special palette has been set, or after unsetPalette() has been called, this is either a special palette for the widget class, the parent's palette or (if this widget is a top level widget), the default application palette.
.PP
Instead of defining an entirely new palette, you can also use the paletteBackgroundColor, paletteBackgroundPixmap and paletteForegroundColor convenience properties to change a widget's background and foreground appearance only.
The palette background color is usually set implicitly by setBackgroundMode(), although it can also be set explicitly by setPaletteBackgroundColor(). setPaletteBackgroundColor() is a convenience function that creates and sets a modified TQPalette with setPalette(). The palette is modified according to the widget's background mode. For example, if the background mode is PaletteButton the color used for the palette's TQColorGroup::Button color entry is set.
If there is a background pixmap (set using setPaletteBackgroundPixmap()), then the return value of this function is indeterminate.
.PP
See also paletteBackgroundPixmap, paletteForegroundColor, palette, and colorGroup.
.PP
Set this property's value with setPaletteBackgroundColor(), get this property's value with paletteBackgroundColor(), and reset this property's value with unsetPalette().
The palette background pixmap is usually set implicitly by setBackgroundMode(), although it can also be set explicitly by setPaletteBackgroundPixmap(). setPaletteBackgroundPixmap() is a convenience function that creates and sets a modified TQPalette with setPalette(). The palette is modified according to the widget's background mode. For example, if the background mode is PaletteButton the pixmap used for the palette's TQColorGroup::Button color entry is set.
If there is a plain background color (set using setPaletteBackgroundColor()), then this function returns 0.
.PP
See also paletteBackgroundColor, paletteForegroundColor, palette, and colorGroup.
.PP
Set this property's value with setPaletteBackgroundPixmap(), get this property's value with paletteBackgroundPixmap(), and reset this property's value with unsetPalette().
setPaletteForegroundColor() is a convenience function that creates and sets a modified TQPalette with setPalette(). The palette is modified according to the widget's \fIbackground mode\fR. For example, if the background mode is PaletteButton the palette entry TQColorGroup::ButtonText is set to color.
Set this property's value with setPaletteForegroundColor(), get this property's value with paletteForegroundColor(), and reset this property's value with unsetPalette().
This property holds the position of the widget within its parent widget.
.PP
If the widget is a top-level widget, the position is that of the widget on the desktop, including its frame.
.PP
When changing the position, the widget, if visible, receives a move event (moveEvent()) immediately. If the widget is not currently visible, it is guaranteed to receive an event before it is shown.
This property holds the size of the widget excluding any window frame.
.PP
When resizing, the widget, if visible, receives a resize event (resizeEvent()) immediately. If the widget is not currently visible, it is guaranteed to receive an event before it is shown.
The size is adjusted if it lies outside the range defined by minimumSize() and maximumSize(). Furthermore, the size is always at least TQSize(1, 1). For toplevel widgets, the minimum size might be larger, depending on the window manager.
This property holds the recommended size for the widget.
.PP
If the value of this property is an invalid size, no size is recommended.
.PP
The default implementation of sizeHint() returns an invalid size if there is no layout for this widget, and returns the layout's preferred size otherwise.
This property holds the size increment of the widget.
.PP
When the user resizes the window, the size will move in steps of sizeIncrement().width() pixels horizontally and sizeIncrement.height() pixels vertically, with baseSize() as the basis. Preferred widget sizes are for non-negative integers \fIi\fR and \fIj\fR:
.PP
.nf
.br
width = baseSize().width() + i * sizeIncrement().width();
If there is a TQLayout that manages this widget's children, the size policy specified by that layout is used. If there is no such TQLayout, the result of this function is used.
The default policy is Preferred/Preferred, which means that the widget can be freely resized, but prefers to be the size sizeHint() returns. Button-like widgets set the size policy to specify that they may stretch horizontally, but are fixed vertically. The same applies to lineedit controls (such as TQLineEdit, TQSpinBox or an editable TQComboBox) and other horizontally orientated widgets (such as TQProgressBar). TQToolButton's are normally square, so they allow growth in both directions. Widgets that support different directions (such as TQSlider, TQScrollBar or TQHeader) specify stretching in the respective direction only. Widgets that can provide scrollbars (usually subclasses of TQScrollView) tend to specify that they can use additional space, and that they can make do with less than sizeHint().
Calling update() and repaint() has no effect if updates are disabled. Paint events from the window system are processed normally even if updates are disabled.
.PP
setUpdatesEnabled() is normally used to disable updates for a short period of time, for instance to avoid screen flicker during large changes.
.PP
Example:
.PP
.nf
.br
setUpdatesEnabled( FALSE );
.br
bigVisualChanges();
.br
setUpdatesEnabled( TRUE );
.br
repaint();
.br
.fi
.PP
See also update(), repaint(), and paintEvent().
.PP
Set this property's value with setUpdatesEnabled() and get this property's value with isUpdatesEnabled().
.SH "bool visible"
This property holds whether the widget is visible.
.PP
Calling show() sets the widget to visible status if all its parent widgets up to the top-level widget are visible. If an ancestor is not visible, the widget won't become visible until all its ancestors are shown.
.PP
Calling hide() hides a widget explicitly. An explicitly hidden widget will never become visible, even if all its ancestors become visible, unless you show it.
.PP
A widget receives show and hide events when its visibility status changes. Between a hide and a show event, there is no need to waste CPU cycles preparing or displaying information to the user. A video application, for example, might simply stop generating new frames.
.PP
A widget that happens to be obscured by other windows on the screen is considered to be visible. The same applies to iconified top-level widgets and windows that exist on another virtual desktop (on platforms that support this concept). A widget receives spontaneous show and hide events when its mapping status is changed by the window system, e.g. a spontaneous hide event when the user minimizes the window, and a spontaneous show event when the window is restored again.
.PP
See also show(), hide(), hidden, isVisibleTo(), minimized, showEvent(), and hideEvent().
\fBWarning:\fR Changing this property from opaque to transparent might issue a paint event that needs to be processed before the window is displayed correctly. This affects mainly the use of TQPixmap::grabWindow(). Also note that semi-transparent windows update and resize significantely slower than opaque windows.
