Re: Why does _WRAP_SIGNAL look for signal in base class?

[Murray Cumming <murrayc murrayc com>]

On Fri, 2012-03-02 at 12:24 +0000, A J Delaney brighton ac uk wrote:
> Dear all,
> 	I'm trying to expose the "collision" signal of a ClutterBox2DChild.
> I've wrapped the class as per the documentation (included below) which
> uses the _WRAP_SIGNAL() macro.  The generated code (immediately below)
> gets the parent class of the current object's class and then looks for
> the "collision" signal handler in the base class.  However, in general
> g_signal_new is used to create a new signal which is normally stored in 
> static gint my_type_signals[LAST_SIGNAL];
> rather than being stored in some structure in the base class.
> 
> My question is, why then does the generated code from _WRAP_SIGNAL try
> and access base->the_signal_name?

That would be the default signal handler. Not all signals have a default
signal handler, though 99% of them do. It is sometimes not used for new
signals when the developer wants to prevent an ABI break.

That seems to be the case here:
http://git.gnome.org/browse/clutter-box2d/tree/clutter-box2d/clutter-box2d-child.cpp#n464

Compare that to this, more normal one, for instance:
http://git.gnome.org/browse/gtk+/tree/gtk/gtkbutton.c#n357

You can use the no_default_handler optional parameter, as mentioned
here:
http://developer.gnome.org/gtkmm-tutorial/unstable/sec-wrapping-hg-files.html.en#gmmproc-wrap-signal

[snip]
>   _WRAP_SIGNAL(void
> collision(Glib::RefPtr<Clutter::Box2D::Box2DCollision> & c),
> "collision")
> };

You probably want that to be a _const_ &. And maybe even a
RefPtr<const ...>

-- 
murrayc murrayc com
www.murrayc.com
www.openismus.com