Re: [gtk-list] Apprarently simple signal/event question



"Peter Wright" <dafrog@dapad.co.uk> writes:
> 
> I have a problem understanding why something happens, which on the surface
> would appear to be quite simple.
> 
> I understand that the callback on signals looks like this
> 
>     gint signalblahblah( GtkWidget *, gpointer *)
>

This isn't true - the callback can have many different types. You need
to check for each signal and verify its signature in the reference docs.
However, this is probably the most common type with two changes:
 - it's plain "gpointer" not "gpointer*"
 - no return value - returning a value when "void" is expected 
   usually causes memory corruption

> ...and according to the documentation out there, a callback for an event
> would look like this
> 
>     gint eventblahblah( GtkWidget *, GdkEvent*, gpointer *)
> 

There's a terminology problem here: this is the callback that the
_signals_ emitted _in response to events_ have. (except it's gpointer,
not gpointer* again).

The GDK chapter in my book talks about signals vs. events,
http://developer.gnome.org/doc/GGAD/

> So, given that, why then can I connect the first format of handler function
> to the delete_event event. Ie.
> 
> gtk_signal_connect( GTK_OBJECT(MyWindow),
>                     "delete_event",
>                     GTK_SIGNAL_FUNC( signalblahblah ),
>                     NULL );
> 
> It occurs to me that based on what the docs say, that I should get an error
> for connecting a signal handler to what is obviously an event. I don't, the
> code works, and I've seen in numerous other pieces of code.
> 

The code works as long as you don't try to use the gpointer, because
you will get the second arg of the signal (GdkEvent*) instead. 
Since the first argument (GtkWidget*) is the same for both callbacks
it will work.

There is no way in C to ask for the type of a callback, so no way for
GTK+ to check that type. So you simply have to get it right. If you
get the wrong type, sometimes it's harmless, sometimes you corrupt
memory. ;-)

Havoc





[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]