views:

87

answers:

1

As the subject says, I'm posting events from non-GUI thread (some GStreamer thread, to be precise). Code looks like this:

GstBusSyncReply on_bus_message(GstBus* bus, GstMessage* message, gpointer data)
{
    bool ret = QMetaObject::invokeMethod(static_cast<QObject*>(data), "stateChanged", Qt::QueuedConnection);
    Q_ASSERT(ret);

    return GST_BUS_PASS;
}

The problem is, stateChanged (doesn't matter whether it is a slot or signal) is not called. I've stepped into QMetaObject::invokeMethod with debugger, followed it till it called PostMessage (it is Qt 4.6.2 on Windows, by the way) – everything seemed to be OK.

Object pointed to by data lives in GUI thread, I've double-checked this.

How can I debug this problem? Or, better, maybe sidestep it altogether?

A: 

0h my god.

I am so stupid.

I've spent literally days debugging this.

And the problem looked like this:

bool VideoWidget::even(QEvent* e)
{
    if (!impl_)
        return false;

    // ...
}

Yes, I've reimplemented QObject::event() (to add some special processing for show/hide and resize events), and did not call the base method. And, guess what, Qt::QueuedConnection uses QEvents to make the deferred calls.

Never do things like I did. Really.

Or, dear Qt, can you please use NVI to guard us against this sort of mistakes?

gp