Tuesday's 5c Hint for PyGTK programmers:
Lock variables are great for avoiding recursive loops in callbacks.
On Tue, Sep 09, 2003 at 06:01:04PM +0200, I�igo Serna wrote:
> ok, ok, it works, 2 minutes after answering I've understood where to put
> the if-clause. It seems gtk just needs to call the callback to update
> the visual look of the widget, although it doesn't execute anything.
Actually, the *default* callback, which is coded in C and lives inside
GTK+, takes care of updating the widget state; your callback is an
"extra" in the sense that it allows you to do extra work beyond the
updating of the UI (which GTK+ does for you).
The key in understanding this is noticing that you call
self.toggle.set_active()
-- and not self.onToggleToggled() -- set_active() emits a toggled
signal. The UI update is handled by the default handler, and your
handler is called to do whatever you like.
Note that the order in which the default handler and your handler are
called varies depending on the widget and the signal, though *usually*
default handlers run early in the emission process. Using
connect_after() *normally* ensures that your custom handler runs last in
the process, which would allow you to use get_active() instead of
relying on the current value of self.opt (though the final effect is
practically the same).
> Sorry for previous mail and thanks a lot Christian.
Not at all, and no problem.
Take care,
--
Christian Reis, Senior Engineer, Async Open Source, Brazil.
http://async.com.br/~kiko/ | [+55 16] 261 2331 | NMFL
_______________________________________________
pygtk mailing list [EMAIL PROTECTED]
http://www.daa.com.au/mailman/listinfo/pygtk
Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/
