QListWidget itemClicked and itemDoubleClicked - block single click if double click

So far I have this code, which works fine:

QObject::connect(mListWidget, SIGNAL(itemDoubleClicked(QListWidgetItem*)), this, SLOT(itemDoubleClicked(QListWidgetItem*)));
QObject::connect(mListWidget, SIGNAL(itemClicked(QListWidgetItem*)), this, SLOT(itemClicked(QListWidgetItem*)));

The problem is that every time I double click on an item, the itemClicked slot gets executed.

Can I block the itemClicked slot if the user double clicks on an item? So just itemDoubleClicked gets executed?


Actually double clicking on an item produces both itemClicked and itemDoubleClicked signals: click + click. You can use a timer and check after timeout whether the itemDoubleClicked signal occurred soon after itemClicked, and if yes, ignore the itemClicked signal.

Thanks to vahancho for the idea, to use a timer. Here is my solution:


    QListWidgetItem* mSingleClickedItem;
    bool mDoubleClicked;

private slots:
    void itemClickedTimeout();


void YourClass::itemClicked(QListWidgetItem* listWidgetItem) {
    if (!mDoubleClicked) {
        QTimer::singleShot(300, this, SLOT(itemClickedTimeout()));
        // use QApplication::doubleClickInterval() instead of 300
        mSingleClickedItem = listWidgetItem;

void YourClass::itemClickedTimeout() {
    if (!mDoubleClicked) {
        // do something, listitem has been clicked once
    } else mDoubleClicked = false;

void YourClass::itemDoubleClicked(QListWidgetItem* listWidgetItem) {
    mDoubleClicked = true;

    // do something, listitem has been clicked twice

Need Your Help

Run-Time Check Failure #2 - Stack around the variable 'indices' was corrupted

c++ c visual-studio

well I think I know what the problem is. I am just having a hard time debugging it. I am working with the directx api and I am trying to generate a plane along the x and z axis according to a book ...

Calling Oracle "DEFINE" from Java

java sql oracle jdbc oracle11g

I need to define some variables in Oracle to be used further down our application's database installation scripts. Basically, the way our installer works now is it reads in the script files and calls