bugfix: another crash when cleaning up signals While 769130f51a8f did fix one issue, it introduced another by changing the logic related to the new SignalTracker. The original logic (introduced in 9ad388c5bf16) was: -> in 'leave(Signal)', only call 'disconnect' -> in 'leaveAll()', call 'disconnect' and 'disconnectTracker' But 769130f51a8f inverted this, calling 'disconnectTracker' in both cases but only 'disconnect' in the 'leaveAll()' case, which would leave unattached signals around after calling 'leave(Signal)'. This fix not only repairs the logic, but renames the ambiguous 'disconnect' boolean to something more explicit: 'withTracker'.
Jim Ramsay i.am@jimramsay.com
1 files changed,
4 insertions(+),
4 deletions(-)
jump to
M
src/FbTk/Signal.hh
→
src/FbTk/Signal.hh
@@ -242,14 +242,14 @@ }
/// Leave tracking for a signal /// @param id the \c id from the previous \c join - void leave(TrackID id, bool disconnect = false) { + void leave(TrackID id, bool withTracker = false) { // keep temporary, while disconnecting we can // in some strange cases get a call to this again ValueType tmp = *id; m_connections.erase(id); - if (disconnect) - tmp.first->disconnect(tmp.second); - tmp.first->disconnectTracker(*this); + tmp.first->disconnect(tmp.second); + if (withTracker) + tmp.first->disconnectTracker(*this); } /// Leave tracking for a signal