Re: Fwd: Re: stopping signals

[Gus Koppel <gtk spamkiller bytechase cx>]

dave walters wrote:

> 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().

You don't need to stop signal emission. Just make your signal handlers
pay attention to a flag variable of your own, like "dont_set_values". If
set the signal handler of your spinbutton should simply return without
fixing any values. The order would basically be:

1. 1st spinbutton handler is being invoked by user changing value.
2. Handler sets flag.
3. Handler changes values of other spinbuttons as needed.
4. Other handlers are invoked but do nothing because of the flag.
5. 1st handler clears flag and exits.

This is infinite recursion avoidance, the easy way.