Fwd: Re: stopping signals

[dave walters <walter8950 yahoo com>]

--- Sven Neumann <sven@gimp.org> wrote:
> To: dave walters <walter8950@yahoo.com>
> CC: gtk-list@gnome.org
> Subject: Re: stopping signals
> From: Sven Neumann <sven@gimp.org>
> Date: 17 Nov 2003 02:28:28 +0100
> 
> 
> I don't understand the reason for this particular
> callback construct
> but since in general user interface elements often
> need to be updated
> from callback functions and the recursiveness you
> describe is causing
> problems for GObject newbies, here's how to solve
> this problem:
> 
> Either block the "value_changed" signal handler
> using
> g_signal_handlers_block_by_func() before you set the
> value and unblock
> it later or compare the set value with the new one
> and only set the
> value if the two differ.
> 
> 
> Sven
> 
I tried g_signal_handlers_block_by_func() but it
didn't work either. I think stopping the signal would
be best but I can't get it to work inside the
callback.

Here is the problem to solve:
You have an hbox and pack_start some integer spins
into it. You want the values on the spins to be in
strictly increasing order from left to right at all
times, thus:

spin1 < spin2 < spin3 (etc if more spins)

The lowest value for spin1 is 1.
It is easy enough to program except for the recursive
problem. But it can be solved anyway if that is
explicitly taken into consideration. I will just need
to twiddle the code a little. I think the best way is
to stop the spin from emitting the "value_changed"
signal temporarily in the callback before set_value().

Walt


__________________________________
Do you Yahoo!?
Protect your identity with Yahoo! Mail AddressGuard
http://antispam.yahoo.com/whatsnewfree