is it possible to disconnect without storing `sigc::connection'?

Hi,

In C-level GTK+ there is a function named
g_signal_handlers_disconnect_matched().
It can be used to disconnect, for instance, particular
handlers (i.e. with
matching function) of an object.  Is something similar
possible with libsigc++
or do I have to store `sigc::connection' objects around?

Paul
_______________________________________________
libsigc-list mailing list
libsigc-listgnome.org
h
ttp://mail.gnome.org/mailman/listinfo/libsigc-list

Paul Pogonyshev wrote:
 > Hi,
 >
 > In C-level GTK+ there is a function named 
g_signal_handlers_disconnect_matched().
 > It can be used to disconnect, for instance, particular
handlers (i.e. 
with
 > matching function) of an object.  Is something similar
possible with 
libsigc++
 > or do I have to store `sigc::connection' objects
around?

Hi Paul,

When you connect to a signal you get an iterator back from 
signal::connect().
You could use this iterator or copy the slot the iterator
points to and 
then call it->disconnect() or slotcopy.disconnect();

Note however that the iterator is only valid as long as the
signal's 
slot list is valid.
Connections have a trackable mechanism and are therefore
safer.


--
Klaus Triendl
_______________________________________________
libsigc-list mailing list
libsigc-listgnome.org
h
ttp://mail.gnome.org/mailman/listinfo/libsigc-list

klaus triendl wrote:
> Paul Pogonyshev wrote:
>  > Hi,
>  >
>  > In C-level GTK+ there is a function named 
g_signal_handlers_disconnect_matched().
>  > It can be used to disconnect, for instance,
particular handlers (i.e.  with
>  > matching function) of an object.  Is something
similar possible with libsigc++
>  > or do I have to store `sigc::connection' objects
around?
> 
> Hi Paul,
> 
> When you connect to a signal you get an iterator back
from 
> signal::connect().
> You could use this iterator or copy the slot the
iterator points to and 
> then call it->disconnect() or slotcopy.disconnect();
> 
> Note however that the iterator is only valid as long as
the signal's 
> slot list is valid.
> Connections have a trackable mechanism and are
therefore safer.

Right, I know this.  I wondered if I could not store
connection objects,
as I know what handlers _this_ object has connected to a
signal.  I wished
to remove them just by (object + function) pair.

Here is situation I have.   Object A has a pointer to some
model, B.  It
connects to some signals in B to listen for some events. 
Now, if the
model changes to C, A has to disconnect its handlers from B
and connect
them to C instead.  I wondered if I could do that without
storing
connections, as that seems excessive.

Paul
_______________________________________________
libsigc-list mailing list
libsigc-listgnome.org
h
ttp://mail.gnome.org/mailman/listinfo/libsigc-list

On Wed, 2006-10-11 at 21:19 +0300, Paul Pogonyshev wrote:
> Right, I know this.  I wondered if I could not store
connection objects,
> as I know what handlers _this_ object has connected to
a signal.  I wished
> to remove them just by (object + function) pair.
> 
> Here is situation I have.   Object A has a pointer to
some model, B.  It
> connects to some signals in B to listen for some
events.  Now, if the
> model changes to C, A has to disconnect its handlers
from B and connect
> them to C instead.  I wondered if I could do that
without storing
> connections, as that seems excessive.

the not very clearly named
sigc::trackable::notify_callbacks() gets
close to this, but is intended to be called from the
destructor of a
trackable or derived type. it will cause all connections to
the signals
of the object it is called for to be dropped. sigc++ keeps
track of the
connections, you see. but note: i do mean *all* connections.
you have no
control over which ones.


_______________________________________________
libsigc-list mailing list
libsigc-listgnome.org
h
ttp://mail.gnome.org/mailman/listinfo/libsigc-list

Paul Davis schrieb:
> On Wed, 2006-10-11 at 21:19 +0300, Paul Pogonyshev
wrote:
>> Right, I know this.  I wondered if I could not
store connection objects,
>> as I know what handlers _this_ object has connected
to a signal.  I wished
>> to remove them just by (object + function) pair.
>>
>> Here is situation I have.   Object A has a pointer
to some model, B.  It
>> connects to some signals in B to listen for some
events.  Now, if the
>> model changes to C, A has to disconnect its
handlers from B and connect
>> them to C instead.  I wondered if I could do that
without storing
>> connections, as that seems excessive.
> 
> the not very clearly named
sigc::trackable::notify_callbacks() gets
> close to this, but is intended to be called from the
destructor of a
> trackable or derived type. it will cause all
connections to the signals
> of the object it is called for to be dropped. sigc++
keeps track of the
> connections, you see. but note: i do mean *all*
connections. you have no
> control over which ones.

What if you use a trackable special for this purpose, bound
and hidden?

<code>
#include <iostream>
#include <sigc++/sigc++.h>


void func1()
{
  std::cout << "func1" << std::endl;
}

void func2()
{
  std::cout << "func2" << std::endl;
}

int _tmain(int argc, _TCHAR* argv[])
{
  sigc::signal<void> sig;
  sigc::trackable t;

  {
    sig.connect(sigc::bind(sigc::hide(&func1),
sigc::ref(t)));
    sig.emit();
    t.notify_callbacks();
  }
  // does nothing
  sig.emit();

  {
    sig.connect(sigc::bind(sigc::hide(&func2),
sigc::ref(t)));
    sig.emit();
    t.notify_callbacks();
  }
  // does nothing
  sig.emit();

  std::cin.get();

  return 0;
}
</code>

_______________________________________________
libsigc-list mailing list
libsigc-listgnome.org
h
ttp://mail.gnome.org/mailman/listinfo/libsigc-list