Introduction to the QT qwidget class -- Introduction to the QT class (III)

Document directory

• I. Detailed Description
• Ii. Top-level attributes and child components
• Iv. Window flag ID
• 5. introduce several important member functions

I. Detailed Description

The qwidget class is the base class of all user interface objects. In general, basically all UI classes of QT are inherited by qwidget, while qwidget inherits from qobject,
You can refer to QT source to find some subtle writing methods. For example, this article details the object data declaration and usage of the QT library.

Window Level

A widget is an atomic part of the user interface. It receives mouse, keyboard, and other events from the window system and draws its own performance on the screen. Each widget is a rectangle arranged in the z-axis order. A widget can be covered by its parent widget or its front widget.

Qdialog is the most common top-level window. A widget that is not embedded into a parent widget is called a top-level widget. In general, top-level widgets are windows with frames and title bars (although these decorations may not be available when you create top-level widgets if you use a certain part marker .) In QT, The subclass of qmainwindow and different qdialog is the most common top-level window. A widget without a parent widget is always a top-level widget. A non-top-level widget is a child widget. They are child windows in their parent widget. Generally, you cannot distinguish a child widget from its parent widget visually. Most other widgets in QT are useful only as child widgets. (Of course, it is also possible to use a button as a top-level window component, but most people prefer to put their buttons in other buttons, such as qdialog .)

Qwidget has many member functions, but some of them have a small number of direct functions. For example, qwidget has a font attribute, but it is never used by itself. Many sub-classes that inherit it provide actual functions, such as qpushbutton, qlistbox, and qtabdialog.

Each widget constructor accepts one or two standard parameters:

1. qwidget * parent = 0 is the parent widget of the new widget. If it is 0 (default), the new widget is a top-level widget. If not, it will make a child of the parent and be forced by the geometric shape of the parent (unless you specify wtype_toplevel as the part marker ).
2. wflags f = 0 (when available). The default setting is applicable to almost all Widgets. However, for example, A top-level widget without a window system framework, you must use a specific flag.

Ii. Top-level attributes and child components

A widget without a parent widget is always an independent window (top-level widget). For these widgets,
A component without a parent component is usually a window with the top-level attribute. For such components, setwindowtitle () and setwindowwicon () are both valid.

III. Basic events of qwidget events

* Paintevent ()-called as long as the widget needs to be re-painted. It is wise that each widget to display the output must implement it and draw it on the screen outside of paintevent.

* Resizeevent ()-called when the widget is redefined for an hour.

* Mousepressevent ()-called when the mouse key is pressed. There are six mouse-related events, but the mouse clicking and mouse releasing events are the most important events so far. When the mouse is inside the widget or when it uses grabmouse () to capture the mouse, it receives the mouse press event.

* Mousereleaseevent ()-called when the mouse key is released. When a widget receives a mouse-down event, it receives the mouse-release event. This means that if you press the mouse in your widget, drag the mouse to another place, and release the widget, your widget will receive the release event. Here is an exception: If the mouse key is pressed in the pop-up menu, the pop-up menu will immediately steal the mouse event.

* Mousedoubleclickevent ()-it may not look the same as it. If you double-click a widget, the widget receives one or two mouse movement events, one mouse release event, and the last one. You cannot identify a click from a double-click Until you see whether the second click has arrived. (This is why double-click is a single-click extension, rather than a trigger of different behaviors, for most books on the graphic user interface .)

If your widget contains only child widgets, you may not need to implement any event processor. If you want to detect the mouse clicks in the Child widget, call the hasmouse () function of the Child widget in the mousepressevent () of the parent widget.

To receive the windows of the keyboard, You need to implement more event processors:

* Keypressevent ()-it is called as long as the key is pressed and when the key has been pressed for a long enough time. Note that if the tab and SHIFT + TAB keys are used in the focus conversion mechanism, they are only passed to the window component. To force keys to be processed by your widgets, you must implement qwidget: event () again ().

* Focusinevent ()-This function is called when the Window widget obtains the keyboard focus (assuming you have already called setfocuspolicy. Well-written widgets mean they can achieve keyboard focus in a clear but careful way.

* Focusoutevent ()-called when the keyboard focus of a widget is lost.

Some Widgets may need to implement some less common event processors:

* Mousemoveevent ()-The mouse is called as long as the mouse key is pressed. For example, this is useful for dragging. If you call setmousetracking (true), even if no mouse key is pressed, you will also get the mouse movement event. (Note that this application that uses mouse tracking is not very useful in low X connections .) (You can also refer to the drag and drop information .)

* Keyreleaseevent ()-it is called as long as the key is released and when it is automatically repeated and is pressed for a period of time. In this case, the widget receives a key release event and immediately has a key-press event for each duplicate. Note that if the tab and SHIFT + TAB keys are used in the focus conversion mechanism, they are only passed to the window component. To force keys to be processed by your widgets, you must implement qwidget: event () again ().

* Wheelevent ()-When a widget has a focus, it is called as long as the user turns the mouse wheel.

* Enterevent ()-it is called when you move the mouse to the screen space of This widget. (This does not include the screen space owned by the Child widgets of This widget .)

* Leaveevent ()-called when the mouse leaves the screen space of the widget.

* Moveevent ()-it is called when the widget is moved relative to its parent widget.

* Closeevent ()-it is called when the user closes the widget (or when close () is called.

There are also some less obvious events. They are listed in qevent. h and you need to implement event () again to process them. The default Implementation of event () processes tab and SHIFT + tab (mobile keyboard focus), and the vast majority of other events are given to one or more specific processors mentioned above.

Iv. Window flag ID

For more information about qwidget flags, see the official documentation for the enum QT: windowtype flags QT: windowflags parameters.

There are many windowflags in QT. In actual use, if you do not care about the window level, you may not care too much about this. For example, you can only focus on QT: Dialog, QT: tool, QT: window for application development on Windows. But for Embedded Development, you have to take a good look at this property and sort out this property, which is conducive to window management.

5. Several important member functions, bool qwidget: Close () [Slot]

Close this widget. If the widget is closed, true is returned. Otherwise, false is returned. First, it sends a qcloseevent To This widget. If it receives this close event, it will be hidden. Qwidget: the default Implementation of closeevent () is to receive this close event. When the last visible top-level widget is closed, the qapplication: lastwindowclosed () signal is sent.
Note the enum QT: widgetattribute attribute of the window. The default attribute of the window is QT: wa_macopaquesizegrip. setting this attribute means that the window calls close () and only destroys the UI, there is still a lot of memory space not released in the qwidget. You need to call Delete to destroy the qwidget. If you need to destroy the window when you call close, you can set the QT: wa_deleteonclose attribute for the window.

Bool qwidget: event (qevent * E) [Virtual protection]

This is the main event processor, which processes event E. You can re-implement the entire function in the subclass, but we recommend that you replace it with a specific event processor.
The main event first passes the event to all installed event filters. If no filter intercepts this event halfway, it calls a specific event processor.
The key-press and release events are processed differently from other events. Event () checks the tab and SHIFT + tab and tries to move the focus properly. If no widget is moved into focus (or press a key instead of a tab or SHIFT + TAB), event () calls keypressevent ().
If it can pass an event to nothing, this function returns the truth. Otherwise, if nothing wants this event, it returns false.
You can also refer to closeevent (), focusinevent (), focusoutevent (), enterevent (), keypressevent (), keyreleaseevent (), leaveevent (), mousedoubleclickevent (), mousemoveevent (), mousepressevent (), mousereleaseevent (), moveevent (), paintevent (), resizeevent (), qobject: event (), and qobject: timerevent ().

Void qwidget: paintevent (qpaintevent *) [Virtual protection]

This event processor can be re-implemented in sub-classes to receive draw events.
A draw event is a request to re-draw all parts of this widget. It can be the result of repaint () or update (), or because the widget is dimmed and no longer overwritten, or for many other reasons.
Many widgets re-draw the entire interface easily when they are requested. However, some slow widgets only need to plot the requested region qpaintevent: Region (). This speed optimization will not change the result. During event processing, the rendering only takes place in the changed area. For example, qlistview and qcanvas do this.
Qt also tries to merge multiple draw events into one to speed up painting. When Update () is called several times or the window system sends several draw events, QT combines them into a relatively large area (see qregion: unite ()). Repaint () does not allow such optimization, so we recommend that you use Update () whenever possible ().
When a painting event occurs, the update area is usually erased, so you are painting the background of the widget. Here are some exceptions and qpaintevent: erased () tells you whether the widget is erased.
You can set the background by using setbackgroundmode (), setpalettebackgroundcolor (), or setbackgroundpixmap. The setbackgroundmode () document describes the background in detail. We recommend that you read it.

Void qwidget: Raise () [Slot]

Raise the Widget To the top of its parent widget stack.
If there is a brother that overlaps the widget on the screen, the widget will become visible before it becomes later.
You can also refer to lower () and stackunder ().

Void qwidget: repaint (int x, int y, int W, int H, bool erase = true) [Slot]

You can call paintevent () to re-draw the widget directly, unless the update is invalid or the widget is hidden.

If erase is true, QT erased the region (X, Y, W, h) before paintevent () is called ).

If W is a negative number, it is replaced by width ()-X, and if H is a negative number, it is replaced by height ()-y.

If you need to re-draw immediately, we recommend that you use repaint (), for example, during the animation. In most cases, update () is better because it allows QT to optimize the speed and prevent flickering.

Warning if you call repaint () in a function and it is called by paintevent (), you may see a wireless loop. The Update () function never generates a loop.

You can also refer to update (), paintevent (), updatesenabled, and erase ().