Re: multiple changed events?

On Tue, 2007-09-25 at 13:30 +0100, Dave Howorth wrote:

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

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.

this has *nothing* to do with gtk+, so please don't use it as an
argument. the convention is defined and documented in countless threads
(even on this very mailing list :-)), and as such gtk+ has always had
this kind of behaviour; some applications might even depend on it - so
it's not going to change.

you can use pre-conditions and post-conditions to verify the data before
committing it inside the callback - as you always should, since it's
dealing with user input.

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.

yes. if you are changing the content of the entry with a known value
then you can also call the functions you are calling in the
GtkEntry::changed callback as well. if you can't do that it means you
haven't separated the logic of the application from the UI code - and
this is usually something that bites you back, sooner or later.

[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

It's not documented where it's needed! (i.e. at

then, please: provide a patch for the gtk+ upstream documentation. those
patches are usually applied as soon as received.

see, for instance:

    In general, "changed" signals should be thought of as 
    "something might have changed" rather than as "something


Emmanuele Bassi,

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]