博客

We can reimplement a specific event handler.

Reimplementing event handlers such as

mousePressEvent()

,

keyPress-Event()

, and

paintEvent()

is by far the most common way to process events. We have already seen many examples of this.

We can reimplement QObject::event().

By reimplementing the

event()

function, we can process events before they reach the specific event handlers. This approach is mostly needed to override the default meaning of the Tab key, as shown earlier (p. 164). This is also used to handle rare types of event for which no specific event handler exists (for example,

QEvent::HoverEnter

). When we reimplement

event()

, we must call the base class’s

event()

function for handling the cases we don’t explicitly handle.

We can install an event filter on a single QObject.

Once an object has been registered using

installEventFilter()

, all the events for the target object are first sent to the monitoring object’s

event-Filter()

function. If multiple event filters are installed on the same object, the filters are activated in turn, from the most recently installed back to the first installed.

We can install an event filter on the QApplication object.

Once an event filter has been registered for

qApp

(the unique

QApplication

object), every event for every object in the application is sent to the

event-Filter()

function before it is sent to any other event filter. This approach is mostly useful for debugging. It can also be used to handle mouse events sent to disabled widgets, which

QApplication

normally discards.

We can subclass QApplication and reimplement notify().

Qt calls

QApplication::notify()

to send out an event. Reimplementing this function is the only way to get all the events, before any event filters get the opportunity to look at them. Event filters are generally more useful,




















because there can be any number of concurrent event filters, but only one

notify()

function.