Hi,

Following @KH-219Design suggestion, you should have a task manager rather than relying on the task object itself to do all the job.

Many thanks for all your help,

I now switched from postEvent to sendEvent, so it is not like fire and forget and I can handle the returns.

Also now I can fire a lot of sendEvents and no crash appears anymore. So this solves it for me.

Regards

Hi,

You can modify GUI elements from other threads. You should rather use signals and slots to communicate between both. It will handle the communication properly for you.

Yes that is correct. Every of the 8 custom gestures defines its own set of data in addition to the QGestureState, which is set by the according gesture recognizer.

I now implemented an abstract superclass for all these gestures with a method getGestureData(). This method basically wraps all the data in a QMap<QString,QVariant> to make a general gesture treatment possible. The custom event GestureEvent now takes gesture type, the Qt::GestureState and the mentioned gesture data map.
It was a little bit circumstantial, but now it works.

Thanks again,
Malte

@sinjohr I think this things happen. Working with threads is not always a cool path.

According to the documentation, a QEvent::ThreadChange event is sent to the object just before the thread affinity is changed.

You can try to handle the event.

Another option is using the overloaded method

void QCoreApplication::postEvent(QObject * receiver, QEvent * event, int priority)

and use Qt::LowEventPriority.