Delay action to wait for user interaction

From Qt Wiki
Revision as of 15:15, 14 January 2015 by Maintenance script (talk | contribs)

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search

Delay action to wait for more user input

Usecase

Have you ever created a text filter that can be used to filter a (big) item view so users can get to their content faster? If you did, you probably simply connected
QLineEdit::textChanged ( const QString & text )
to a
QSortFilterProxyModel::setFilterXXX
method, either via your own slot to add some wildcards or wrap the line edit’s string in a regular expression or not. The problem is, now each character typed by the user triggers an update of the whole view, and the proxy model has to go through all the items in your list over and over again. That could get expensive and slow, thereby instead of improving user experience you actually annoy the user…

There are many such cases where events can happen in quick succession, and you’d like your application to respond to these changes. On the one hand, it makes sense to respond to as many of those events in one go as possible, but on the other hand you don’t want the update to take too much time after the user is done typing his filter string (or whatever it is you are waiting for).

Enter DelayedExecutionTimer

One solution to this problem is to use two timers, one short enough so an update will still appear snappy but long enough that it will probably not trigger before there is more input (for instance, if the user is not done typing his filter), and one longer timer that will trigger a set time after the first event happened, so the update will not be delayed forever as more and more events happen that would otherwise delay the update.

The
DelayedExecutionTimer
class implements this approach, making it very easy to apply in all such cases without mucking about with creating, setting and resetting timers for each case where you need this.
DelayedExecutionTimer
basically provides one slot
trigger()
and one signal
triggered()
. Instead of directly connecting the event to the action (connecting the
textChanged()
to the
setFilter()
, for instance), you connect the
QLineEdit::textChanged()
to
DelayedExecutionTimer::trigger()
, and
DelayedExecutionTimer::triggered()
to
QSortFilterProxyModel::setFilter()
.
DelayedExecutionTimer
also provides two more versions of both the trigger() slot and the triggered() signal for convenience. These allow to pass a QString or an int as an argument. The triggered() signal will be emitted without argument, and with both a QString and with an int argument, carrying the last value that was passed in by the corresponding trigger() signal (or a default value if no such value was set). As a last convenience feature, you can set pre- and post- strings, that will be added to the string value before the signal is send. This way, connecting the line edit to the
SortFilterProxy
model becomes as simple as this:

That’s all. Of course, you can tweak the timings by either passing in a reasonable minimum and maximum delay in the constructor, or using the setters for these.

Code

delayedexecutiontimer.h

And here’s the CPP code:

delayedexecutiontimer.cpp

Categories: