| |
Given the many different options when creating signals
and connecting callbacks, you may be thoroughly confused
about what happens when a signal is emitted. Here's a
summary of the sequence of events:
-
If you are emitting the signal by name, the signal ID
is looked up.
-
If another emission of the same signal is in
progress, and the signal has the GTK_RUN_NO_RECURSE flag set, GTK+
signals the previous emission to restart and this
emission ends.
-
If the signal is
GTK_RUN_FIRST, the default signal handler is
called using the signal's marshaller. If the emission
is stopped from within the handler, (using gtk_emit_stop_by_name() or one of its
cousins), this emission ends. If the signal is
re-emitted from within the handler and is GTK_RUN_NO_RECURSE, this
emission restarts.
-
If there are any emission hooks installed for this
signal, they are invoked. GTK+ does not check whether the emission has
been stopped or re-emitted at this point; it will not
check until the next step. Emission hooks should not
re-emit the signal they are watching, or try to stop
the emission.
-
Any normally-connected callbacks are invoked using
the signal's marshaller. Callbacks connected with gtk_signal_connect_after() are
not invoked at this point. After invoking each
callback, GTK+ checks whether it stopped the signal
and the emission ends if so. GTK+ also checks whether
the signal was re-emitted, and if so restarts the
emission process for
GTK_RUN_NO_RECURSE signals.
-
If the signal is
GTK_RUN_LAST, the default handler is invoked.
Afterward GTK+ again checks whether the emission has
been stopped or should be restarted.
-
Any callbacks connected with
gtk_signal_connect_after() are invoked. After
invoking each one, GTK+ checks whether the emission
should be stopped or restarted.
Within each step the handlers are invoked in the order
they were connected. The order of the steps is fixed:
GTK_RUN_FIRST default
handler, emission hooks, normal connections, GTK_RUN_LAST default handler, "after"
connections.
|
|
