Hi,
What happens if the same signal and slot is connected twice? And how is the mechanism handled?
Regards,
+1
A:
Usually bad things. It's perfectly acceptable to connect the slot twice or even more times but when the signal gets fired your slot will be called for each connection you made which is probably not what you want.
Note that it is not necessarily wrong to have multiple connections. There are (probably) perfectly valid uses for it. They are quite rare, I certainly can't think of any time I've used it as a feature. All the situations I can recall where there was a multiple connection turned out to be a bug rather than intended.
Troubadour
2010-08-20 11:58:06
Ok, What exactly is there in the moc file? doesnt it have any capability to handle this kind of scenarios of prpgramming mistakes?
itapadar
2010-08-20 11:59:36
@itapadar: I don't think they bother trying to prevent it because it might _not_ be a mistake. I wrote some code not that long ago that actually relied on that feature in some situations.
Troubadour
2010-08-20 12:02:06
@itapadar: Actually on thinking back I didn't use it as a feature at all. It appeared as a bug and I had to work around it.
Troubadour
2010-08-20 12:14:15
+8
A:
A few weeks ago, we had an intern accidentally connect a signal to a slot more than once. The idea was that under one condition, you'd have the slot connected to the signal, and under another condition you'd disconnect it. When you changed modes, you'd do the appropriate work.
Well, he forgot to to disconnect when appropriate. So every time you changed modes, you had a new connection to the slot.
The end result? 1 connection == 1 call to slot. 2 connections == 2 calls to slot. 3 connections == 3 calls to slot, etc. These calls happened "simultaneously" (I know in actuality they did not since they are on the same event thread, but what I mean was all calls were processed in succession).
As @Job points out in one of his comments (he deserves credit, so please do not upvote me for his work), http://doc.trolltech.com/latest/qt.html#ConnectionType-enum will prevent this issue.
San Jacinto
2010-08-20 12:12:32
Note that you can use [Qt::UniqueConnection](http://doc.trolltech.com/latest/qt.html#ConnectionType-enum) to prevent this scenario.
Job
2010-08-20 12:32:27
@Job: I would add an answer with that in it. I wasn't aware that that had been added to Qt. Thanks for pointing it out.
Troubadour
2010-08-20 12:34:26
@Troubadour: I don't feel like hijacking San Jacinto's answer :-) Maybe he could add it to his answer.
Job
2010-08-20 12:38:08
@Job: You wouldn't have been hijacking any answer. Nobody had mentioned `Qt::UniqueConnection` when you commented.
Troubadour
2010-08-20 12:48:58
@Troubadour: True but the question is about what actually happens, not about how to prevent it.
Job
2010-08-20 13:02:50
A:
The slot is executed multiple times (as others said already).
Some more notes:
- In former times, the pattern for "connect exactly once" in cases where there might have been a connection before, was to first call disconnect and then connect to enforce exactly one connection.
- Now, since 4.6, there is also the more elegant Qt::UniqueConnection, see http://doc.qt.nokia.com/4.6/qt.html#ConnectionType-enum
Frank
2010-08-20 12:41:46
I'm not so sure it's a more elegant solution. Usually the code should be symmetric and if it's not then that's a bug. I worry that `Qt::UniqueConnection` might be used to patch sloppy asymmetric code more times than it's used for any other purpose.
Troubadour
2010-08-20 12:51:41
Yeah, one can argue that both "connecting once" approaches are not nice. OTOH, if you get an object handed in from somewhere else, potentially multiple times the same object, and all you must do is to listen to some signal (once), then the only other way i can think of is to keep lists of the objects you already have seen. Not nice either.And disconnect(), connect() is a bit fragile, as one has to take care to keep them in sync if something changes. So I'd prefer UniqueConnection. In practice, I see neither "connect once" approach very often so it seems to be not a big problem.
Frank
2010-08-20 13:30:59