Qt wiki will be updated on October 12th 2023 starting at 11:30 AM (EEST) and the maintenance will last around 2-3 hours. During the maintenance the site will be unavailable.

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 Jump to 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: