Fwd: Re: stopping signals
- From: dave walters <walter8950 yahoo com>
- To: gtk-app-devel-list gnome org
- Subject: Fwd: Re: stopping signals
- Date: Tue, 18 Nov 2003 08:24:42 -0800 (PST)
--- 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
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]