Signals & slots

[wysota]

What is the type of ui->widget?

[igoreshka3333]

Type is Scene.

[d_stranz]

Is "Scene" derived from QWidget? Is it a widget you have added to MainWindow using Qt Designer, and you have named it "widget"? If both of these are true, then the problem might be because you defined your slot / signal pair to use "const int &" as an argument, but your connect statement just says "int".

[igoreshka3333]

It both true, thanks) But i forgott to say one thing: there is another class "Game", wherein a change, that I need! May it is a reason?

[wysota]

Do you get any warnings about signals or slots on the console while the application is running?

[Radek]

Some notes:
(1) Is Scene a Q_OBJECT ? It does not suffice that it is derived from a Q_OBJECT. Only Q_OBJECTs can declare slots and signals.
(2) Have you got linker or run time errors (as Wysota has asked)? You should because there is no slot slotSetStatus(int) in sight. Similarly, signalShowStatus(int) isn't declared. int and int& are different types.
(3) Do not count on sync. Your signal brings a reference to a local object which need not exist when the slot is triggered because sendStatus() has returned in the meantime. Either emit signalShowStatus(m_game.segment()) or signal an int instead of a reference.

[anda_skoa]

(1) Is Scene a Q_OBJECT ? It does not suffice that it is derived from a Q_OBJECT. Only Q_OBJECTs can declare slots and signals.

Same for the MainWindow.
It is actually more likely to be missing in the receiver class, since a missing MOC run on a sender class leaves the signal function unimplemented, which leads to a build error.

You should because there is no slot slotSetStatus(int) in sight. Similarly, signalShowStatus(int) isn't declared.

They look both ok.

int and int& are different types.

Yes, but "int" and "const int&" are as far as signal/slots are concerned.

That's why we usually just use "QString" in SIGNAL and SLOT macros, despite the method signature usually being "const QString&".
The signal/slot system calls this "normalized signatures".

(3) Do not count on sync. Your signal brings a reference to a local object which need not exist when the slot is triggered because sendStatus() has returned in the meantime.

No. This here is effectively a Qt:irectConnection. The signal returns once all connected slots have been executed.

Cheers,
_