How to send mouse clicks to a `QTreeWidgetItem` in my test?
-
Hello,
QTreeWidgetItemdoesn't derive fromQObjectat 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.
-
Hello,
QTreeWidgetItemdoesn't derive fromQObjectat 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.
-
@kshegunov Hej, that is a signal, so not useful for me - I want to simulate the click that eventually produces that signal.
@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
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.
-
@kshegunov Hm, that still doesn't do it - the main issue is that simply invoking the slot, will not change the
checkStateof the item, which is what I need@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)); } -
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
QWidgethave theclick()-method, but theQTreeWidgetItemdoes not derive fromQWidgethence doesn't have that method. Similarly, also theQTest::mouseClick()method can only act on aQWidget-derived class. So these two routes don't work.What route will work?
-
@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)); }@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 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) -
@Jakob
Hmmm, I always thought that signals' access specifier isprotected... that is strange. -
@kshegunov As it turns out, line 72 in qobjectdefs.h (Qt 5.4.0) says:
# define Q_SIGNALS public@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 theQMetaObjectclass.
