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

[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.