Как узнать кто излучил сигнал?

[juvf]

В слоте нужно узнать адрес объекта, который испустил сигнал. Можно конечно в параметрах сигнала передавать адрес. А можно ещё как-нибудь? Вроде в Qt для этого есть какие-то методы?

[Fat-Zer]

sender() - прям и не догадаешься...

[Disaron]

QObject::sender()

[Denjs]

QObject::sender()

старая песня о главном))) в общем случае - вы и не должны знать. никак и никогда.
про QObject::sender()- как помню, ассистант рассказывает следующее: данный метод противоречит философии сигнал-слотов и работает только внутри одного потока. Если сигнал из другого потока - то метод возвращает "ничего" (оно и понятно - к моменту получения сигнала объект-источник давно уже мог быть уничтожен)

Более того - понимаю так, что из этого следует и то, что работать оно не будет и в одном потоке если метод вызова слота - "квотед коннекшн".
Возможно и при некоторых других типах соединений - тоже (в 4.5 ввели  новые типы соединений - потому и не знаю).

В общем, имхо, ссылка на объект-источник типа QPointer передаваемая с сигналом - это получше будет и поуниверсальнее, хотя и "более тяжелая конструкция". но QPointer::isNull() удобен.

[Disaron]

QObject::sender()

старая песня о главном))) в общем случае - вы и не должны знать. никак и никогда.
про QObject::sender()- как помню, ассистант рассказывает следующее: данный метод противоречит философии сигнал-слотов и работает только внутри одного потока. Если сигнал из другого потока - то метод возвращает "ничего" (оно и понятно - к моменту получения сигнала объект-источник давно уже мог быть уничтожен)

Более того - понимаю так, что из этого следует и то, что работать оно не будет и в одном потоке если метод вызова слота - "квотед коннекшн".
Возможно и при некоторых других типах соединений - тоже (в 4.5 ввели  новые типы соединений - потому и не знаю).

В общем, имхо, ссылка на объект-источник типа QPointer передаваемая с сигналом - это получше будет и поуниверсальнее, хотя и "более тяжелая конструкция". но QPointer::isNull() удобен.

Замечательное и полезное пояснение, но топикстартер не указал нюансы, которых судя по вопросу и нет. Поэтому кратко: каков вопрос - таков ответ. А в дефолтных условиях однопоточности и дефолтном же состоянии соединения сигнала со слотом - работать будет.

[juvf]

QObject::sender()

старая песня о главном))) в общем случае - вы и не должны знать. никак и никогда.
про QObject::sender()- как помню, ассистант рассказывает следующее: данный метод противоречит философии сигнал-слотов и работает только внутри одного потока. ....

В общем, имхо, ссылка на объект-источник типа QPointer передаваемая с сигналом - это получше будет и поуниверсальнее, хотя и "более тяжелая конструкция". но QPointer::isNull() удобен.

Спасибо за разъяснение. В моём случае как раз сигнал из др. потока.

[serg_hd]

Если сигнал из другого потока - то метод возвращает "ничего" (оно и понятно - к моменту получения сигнала объект-источник давно уже мог быть уничтожен)

неверно, при типе DirectConnection всё ок

[Fat-Zer]

Если сигнал из другого потока - то метод возвращает "ничего" (оно и понятно - к моменту получения сигнала объект-источник давно уже мог быть уничтожен)

неверно, при типе DirectConnection всё ок

Из другого птока можно только QueuedConnection... всё остальное черевато большими проблеммами...

[Igors]

Из другого птока можно только QueuedConnection... всё остальное черевато большими проблеммами...

QBlockedQueuedConnection гарантирует что отправитель жив (он ждет ответа). Ну конечно если устроит по скорости

[serg_hd]

Из другого птока можно только QueuedConnection... всё остальное черевато большими проблеммами...

не чревато, у меня рабочий проект, веб-серфер работает как раз по такому принципу: второстепенные потоки шлют сигналы на главный гуишный поток (с целью создания qwebview), тип сигнала directconnection. Потоков доходило одновременно до 400, проблем никаких никогда не возникало.

[Fat-Zer]

не чревато, у меня рабочий проект, веб-серфер работает как раз по такому принципу: второстепенные потоки шлют сигналы на главный гуишный поток (с целью создания qwebview), тип сигнала directconnection. Потоков доходило одновременно до 400, проблем никаких никогда не возникало.

у меня тоже на linux'e нормально работало, но при переносе  на винду всё полетело. По сигналу из дочернего потока нужно было сделать ресайз окна... так вот это и падало. Да и прогрес бар не обновлялся.
Дело в том, что при директ коннекшине код ГУИ потока будет исполняться в дочернем потоке, что само по себе опасно. Некоторые системы, например, иксы это могут переваривать, а некоторые - нет. (мог ошибиться в своих выводах)
То что у вас не возникало проблем - ИМХО чистая удача...
ЗЫ: сейчас попробую набросать пример.

[Fat-Zer]

А вот и пример(в аттаче)
Оказывается наврал... на линуксе тоже падает, зато хорошо показыват что так делать нельзя.

[juvf]

Дело в том, что при директ коннекшине код ГУИ потока будет исполняться в дочернем потоке, что само по себе опасно.

Почитал асистент ещё раз про директКонекшн.

The slot is invoked immediately, when the signal is emitted.

Ни слово про то, что слот будет выполнятся в потоке излучателя сигнала.

[Fat-Zer]

juvf, не там читали:

Direct Connection The slot is invoked immediately, when the signal is emitted. The slot is executed in the emitter's thread, which is not necessarily the receiver's thread.

[Disaron]

А вот и пример(в аттаче)
Оказывается наврал... на линуксе тоже падает, зато хорошо показыват что так делать нельзя.

Видимо зависит от линукса и от версии кьют. У меня не падает, но при директе гадит:

Код:

QObject::setParent: Cannot set parent, new parent is in a different thread

что вполне естественно.