Сигнал в синлтон в многопоточом варианте Опции Подписка на тему Сообщить другу Версия для печати Скачать тему Подписка на этот форум Режимы отображения Переключить на: Древовидный Стандартный Переключить на: Линейный

[Abesh]

Читал, все что до чего могли добраться руки, но не помогает (если, честно впервые применяю сигналы\слоты в многопоточности)
читал доку, http://habrahabr.ru/blogs/qt_software/115835/ и оригинал, и еще сверху.

Есть синглтон (TT600Controller) есть класс, наследуемый от Qthread c вот таким вот run-ом:

void HardwareModule::run()
{
    TT600Controller *tt600controller;

    tt600controller=TT600Controller::StartUse(); //или в классике instance()

    this->mutex.unlock();
    exec();
  }

Есть еще простенький класс, наследуемый от QObject c вот такими методом:

bool AngelSensor::start()
{
    QString error;
    controller=TT600Controller::StartUse();
    QObject::connect(this, SIGNAL(connect (uint, QString&) ), controller, SLOT(connect(uint,QString&)) );
    emit connect(1,error);

    return true;
}

Проблема заключается в том, что слот не вызывается.

В указанных статьях что-то говориться про Q_INVOKABLE, но не совсем вкурил как его юзать, тупое копирование доки по этому макросу не спасают ситуацию


Да, вариант с moveToThread вообще не вариант

[Гость_Гость_*]

М-да, надо чаще смотреть в консоль приложения. Выяснилось, что-то в moc не зарегистрированы "ссылочные" типы, т.е (что-то QString&) и если все в одном потоке все нормально, то при копировании в очередь событий, как и обещают тролли, возникают проблемы. При попытке зарегистрировать подобные типы, возникают какие-то ошибки компиляции, с которыми я не стал пока разбираться, а просто убрал все передачи по ссылкам .

[wiz29]

между потоками лучше ссылки не передавать, особенно на объекты библиотеки.

[Abesh]

Ну Qstring это не объект библотеки, а контейнер.
Но иногда приходиться, передавать по ссылкам или указателям, из-за стоимости копирования, гораздо дешевле бывает залочить поток.