Signal/slot responsiveness

[guiQt]

Testing QClipboard class, i wrote:

clipboard = QApplication::clipboard();
connect(clipboard, SIGNAL(changed(QClipboard::Mode)), this, SLOT(clipboardChanged()));

clipboard = QApplication::clipboard();
connect(clipboard, SIGNAL(changed(QClipboard::Mode)), this, SLOT(clipboardChanged()));

To copy to clipboard, switch view to plain text mode 

After an initial proper behavior (10-15 times clipboardChanged slot called after every data change ), app stops working (clipboardChanged not called anymore ).
Any suggestions are greatly appreciated.

[squidge]

Have you tried dataChanged instead ?

[guiQt]

Of course, but had same behavior. The app is an extremely simple clipboard manager that runs in background. After a while (20-30 mins - sorry, can't be more specific, different behavior every time...) app stops working.

[Zlatomir]

The whole application "freeze" or only that slot isn't executed after some time?

In the first case it "smells" like a memory leak, look for resources that allocate 'temporary' memory on the heap, every time that slot is called or with the part of your app that emit the signal.

And in the second look at your variables, they might go out of scope

[guiQt]

The second case.
The signal

void QClipboard::changed(QClipboard::Mode mode)

void QClipboard::changed(QClipboard::Mode mode)

To copy to clipboard, switch view to plain text mode 

is emitted by the system, and no variable is involved in the signal/slot process.

[squidge]

You shouldn't depend on this signal happening when the application is in the background, particularly on MacOS.

If you click on your application window (If it doesn't have one, create one for this test), does it start to work again?

[guiQt]

void QClipboard::dataChanged ()
On Mac OS X and with Qt version 4.3 or higher, clipboard changes made by other applications will only be detected when the application is activated.

This is the reason why i used changed() instead of dataChanged(). However, clicking on the application window (activating it) doesn't solve the problem.

[Zlatomir]

See that "clipboard" or "this" variables don't go out of scope. ("this" is the main window?).
I think that if you describe where/how do you create those variables, we will be able to give better advices.

[squidge]

'this' is a C++ keyword. It's not likely to go out of scope :-)

'clipboard' is a pointer to the application global clipboard. Even if it goes out of scope, the original pointer assigned to it will not, so for the purpose of the connect call, it will remain valid for the lifetime of the QApplication object.

[Zlatomir]

You are right about clipboard, sorry, my bad

But "this" is a pointer to the class instance and if the class instance gets destroyed... this can be a possible cause of that behavior, and i don't see any other...