### Tutorial
« Timeouts, IO and Idle Functions... | Managing Selections »

## Advanced Event and Signal Handling

1. The Signal Connection
2. Signal Emission and Propagation.

### The Signal Connection

When you connect a slot to a signal the connection method returns a Connection class.

`Connection connect(SlotType *slot, bool after = false) const`

`
` If you want more control over the signal connection you need to store a copy of this Connection. For example:

`Connection button_connection = button->sig_clicked().connect(slot(this, &MyClass::clicked_signal_handler));`

Then, later you can call one of the three Connection methods which are self explanatory:

`void block(); void unblock(); void disconnect();`

The first method, block(), stops your signal handler from being invoked until unblock() is called. The last method lets you disconnect your slot destroying the signal connection. It is not necessary to disconnect slots at program termination. GTK does this for you automatically.
Inti::G::Signal's do not have an emit method (compare this with Inti::Signals which do). This is because most GTK signals are not meant to be emitted by the user. Rather, they are meant to be emitted by widget implementations. There will be occasions however when you might need to emit a signal. To emit a signal call an object's inherited G::Object::emit_by_name() method:

`void emit_by_name(const char *signal_name, ...);`

The signal_name argument is the name of the GTK signal to emit. This is followed by a list of arguments to pass to the signal handler, followed by a pointer to the return type, if any.

### Signal Emission and Propagation

Signal emission is the process whereby GTK runs all handlers for a specific object and signal. The return value from a signal emission is the return value of the last handler executed. Since event signals are all of type GTK_RUN_LAST, this will be the default (GTK supplied) handler, unless when connecting your slot you specify true for the after parameter. If after is true your slot is connected so that it calls the your signal handler after the other handlers.
The way an event (say "button_press_event") is handled, is:

- Start with the widget where the event occurred.
- Emit the generic "event" signal. If that signal handler returns a value of true, stop all processing.
- Otherwise, emit a specific, "button_press_event" signal. If that returns true, stop all processing.
- Otherwise, go to the widget's parent, and repeat the above two steps.
- Continue until some signal handler returns true, or until the top-level widget is reached.

« Timeouts, IO and Idle Functions... | Index Top | Managing Selections »