How to send mouse clicks to a `QTreeWidgetItem` in my test?

Jakob

I wish to test the response of my application to mouse clicks on single QTreeWidgetItems which are configured to be user selectable.

Objects that derive from QWidget have the click()-method, but the QTreeWidgetItem does not derive from QWidget hence doesn't have that method. Similarly, also the QTest::mouseClick() method can only act on a QWidget-derived class. So these two routes don't work.

What route will work?

kshegunov

Hello,
QTreeWidgetItem doesn't derive from QObject at all. If they did you probably could imagine the amount of overhead it would generate for a simple table/tree widget. I think for your case, you could use the QTreeWidget::itemClicked signal.

Kind regards.

Jakob

@kshegunov Hej, that is a signal, so not useful for me - I want to simulate the click that eventually produces that signal.

kshegunov

@Jakob
Oh, sorry, I'm still sleeping I guess. You could invoke the signal through QMetaObject::invokeMethod by passing your widget as sender and the needed arguments. Hope that helps.

Kind regards.

Jakob

@kshegunov Hm, that still doesn't do it - the main issue is that simply invoking the slot, will not change the checkState of the item, which is what I need

kshegunov

@Jakob
You can change the state externally. Something like this:

void MyClass::clickItem(QTreeWidget * widget, QPoint clickPosition, int checkableColumn)
{
    QTreeWidgetItem * item = widget->itemAt(clickPosition);
    item->setCheckState(checkableColumn, item->checkState() == Qt::Checked ? Qt::Unchecked : Qt::Checked);
    QMetaObject::invokeMethod(widget, "itemClicked", Q_ARG(QTreeWidgetItem *, item), QARG(int, checkableColumn));
}

Jakob

Hm, I just realized the click() method is only on QAbstractButton, not on a generic QWidget. Nevertheless, I really would want to use QTest::mouseClick() to toggle the state of the checkbox of a QTreeWidgetItem.

Jakob

@kshegunov This is indeed what I turned out doing, except that I directly call the signal - apparently that is possible ...... Still not quite what I want but what I'll stick with for now (my main issue with this approach is that this way I don't have a regression for someone erroneously changing the connect()-call)

kshegunov

@Jakob
Hmmm, I always thought that signals' access specifier is protected ... that is strange.

Jakob

@kshegunov As it turns out, line 72 in qobjectdefs.h (Qt 5.4.0) says:

# define Q_SIGNALS public

kshegunov

@Jakob
Ah, yes. From Qt4 you get:
# define Q_SIGNALS protected
I firmly believe that this change was made to accommodate the new way of connecting signals. I don't find it to be a great improvement, but this is a personal opinion ... In the new framework it seems every object can easily rise another object's signal, which is a bit ... hm ... suspicious ... not that it was impossible before, but you had to go the extra mile, by using the QMetaObject class.