Sophie

Sophie

distrib > * > 2010.0 > * > by-pkgid > 345aa895e80053137c21f8693106c3a0 > files > 166

gtkmm2.4-documentation-2.17.4-1mdv2010.0.noarch.rpm

<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<title>Overriding default signal handlers</title>
<link rel="stylesheet" href="style.css" type="text/css">
<meta name="generator" content="DocBook XSL Stylesheets V1.75.1">
<link rel="home" href="index.html" title="Programming with gtkmm">
<link rel="up" href="chapter-signals.html" title="Appendix B. Signals">
<link rel="prev" href="sec-disconnecting-signal-handlers.html" title="Disconnecting signal handlers">
<link rel="next" href="sec-binding-extra-arguments.html" title="Binding extra arguments">
</head>
<body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF">
<div class="navheader">
<table width="100%" summary="Navigation header">
<tr><th colspan="3" align="center">Overriding default signal handlers</th></tr>
<tr>
<td width="20%" align="left">
<a accesskey="p" href="sec-disconnecting-signal-handlers.html"><img src="icons/prev.png" alt="Prev"></a> </td>
<th width="60%" align="center">Appendix B. Signals</th>
<td width="20%" align="right"> <a accesskey="n" href="sec-binding-extra-arguments.html"><img src="icons/next.png" alt="Next"></a>
</td>
</tr>
</table>
<hr>
</div>
<div class="sect1" title="Overriding default signal handlers">
<div class="titlepage"><div><div><h2 class="title" style="clear: both">
<a name="sec-overriding-default-signal-handlers"></a>Overriding default signal handlers</h2></div></div></div>
<p>
So far we've told you to perform actions in
response to button-presses and the like by handling signals.
That's certainly a good way to do things, but it's not the only
way.
</p>
<p>
Instead of laboriously connecting signal handlers to signals,
you can simply make a new class which inherits from a widget - say, a
Button - and then override the default signal handler, such as Button::on_clicked().  This can be a
lot simpler than hooking up signal handlers for everything.
</p>
<p>
Subclassing isn't always the best way to accomplish
things. It is only useful when you want the widget to handle its own signal by itself. If you want some other class to handle the signal then you'll need to connect a separate handler. This is even more true if you want several objects to handle the same signal, or if you want one signal handler to respond to the same signal from different objects.
</p>
<p>
<span class="application">gtkmm</span> classes are designed with overriding in mind; they contain
virtual member methods specifically intended to be overridden.
</p>
<p>
Let's look at an example of overriding:
</p>
<p>
</p>
<pre class="programlisting">
#include &lt;gtkmm/button.h&gt;

class OverriddenButton : public Gtk::Button
{
protected:
    virtual void on_clicked();
}

void OverriddenButton::on_clicked()
{
    std::cout &lt;&lt; "Hello World" &lt;&lt; std::endl;

    // call the base class's version of the method:
    Gtk::Button::on_clicked();
}
</pre>
<p>
</p>
<p>
Here  we define a new class called <code class="classname">OverriddenButton</code>,
which inherits from <code class="classname">Gtk::Button</code>.  The only thing we
change is the <code class="methodname">on_clicked()</code> method, which is called
whenever <code class="classname">Gtk::Button</code> emits the
<code class="literal">clicked</code> signal.  This method prints "Hello World" to
<code class="literal">stdout</code>, and then calls the original, overridden method, to
let <code class="classname">Gtk::Button</code> do what it would have done had we not
overridden.
</p>
<p>
You don't always need to call the parent's method; there are times
when you might not want to.  Note that we called the parent method
<span class="emphasis"><em>after</em></span> writing "Hello World", but we could have called it before.
In this simple example, it hardly matters much, but there are times
when it will.  With signals, it's not quite so easy to change details
like this, and you can do something here which you can't do at all
with connected signal handlers: you can call the parent method in the <span class="emphasis"><em>middle</em></span> of
your custom code.
</p>
</div>
<div class="navfooter">
<hr>
<table width="100%" summary="Navigation footer">
<tr>
<td width="40%" align="left">
<a accesskey="p" href="sec-disconnecting-signal-handlers.html"><img src="icons/prev.png" alt="Prev"></a> </td>
<td width="20%" align="center"><a accesskey="u" href="chapter-signals.html"><img src="icons/up.png" alt="Up"></a></td>
<td width="40%" align="right"> <a accesskey="n" href="sec-binding-extra-arguments.html"><img src="icons/next.png" alt="Next"></a>
</td>
</tr>
<tr>
<td width="40%" align="left" valign="top">Disconnecting signal handlers </td>
<td width="20%" align="center"><a accesskey="h" href="index.html"><img src="icons/home.png" alt="Home"></a></td>
<td width="40%" align="right" valign="top"> Binding extra arguments</td>
</tr>
</table>
</div>
</body>
</html>