[Date Prev][Date Next] [Thread Prev][Thread Next]
[Thread Index]
[Date Index]
[Author Index]
Re: multiple changed events?
- From: Dave Howorth <dhoworth mrc-lmb cam ac uk>
- To: gtk-perl-list gnome org
- Subject: Re: multiple changed events?
- Date: Tue, 25 Sep 2007 13:30:09 +0100
Thanks for the quick response, Emmanuele.
Emmanuele Bassi wrote:
> On Tue, 2007-09-25 at 11:32 +0100, Dave Howorth wrote:
>
>> The changed callback is called twice from within set_text. The first
>> time, the text is an empty string. The second time it is the value that
>> was passed to set_text.
>
> the convention in gtk+ is that any changed signal is emitted at least
> once when "something" changes: there's no upper bound, just the lower
> one[1].
Hmm, I click on a button to make a bank transfer and the transfer
happens twice? I saw this issue once in an inter-bank transfer system.
The recipient said both transfers were correctly authorised and refused
to give the money (a million or two) back :(
> having said this, you can block the emission of a particular signal, or
> the calling of a specific callback. for instance:
>
> $entry->signal_handlers_block_by_func(\&your_entry_callback, $data);
> $entry->set_text('foo');
> $entry->signal_handlers_unblock_by_func(\&your_entry_callback, $data);
>
> will result in your callback not being invoked[2]; you can use this
> inside the callback of the other widget that controls the contents of
> the entry.
AFAICT, this would mean that my callback is not called at all. I need it
to be called once, so I've added my own semaphore around the call to
set_text and a check for the text widget's content being non-empty.
Fortunately I know that this text value can never be empty. But if the
text value could be empty I guess I'd have to set the semaphore before
calling set_text and clear it within the callback. And then I'd be
committed to a specific [buggy, IMHO] implementation of set_text.
> [1] I think there's a bug open, somewhere in bugzilla, for this specific
> instance (making a set_text() atomic); personally, I think it's merely a
> matter of taste: the ::changed signal convention is known and
> documented.
It's not documented where it's needed! (i.e. at
<http://library.gnome.org/devel/gtk/unstable/GtkEditable.html#GtkEditable-changed>
and/or
<http://library.gnome.org/devel/gtk/unstable/GtkEntry.html#gtk-entry-set-text>)
I don't understand how it can be viewed as a matter of taste? But I have
a workaround :)
Thanks again for the reply - at least I know it's not something I've
done wrong.
Thanks, Dave
[Date Prev][Date Next] [Thread Prev][Thread Next]
[Thread Index]
[Date Index]
[Author Index]