Re: [gtk-list] Re: casting func.
- From: pavel <pavel klebanov ne mediaone net>
- To: gtk-list redhat com
- Subject: Re: [gtk-list] Re: casting func.
- Date: Wed, 16 Jun 1999 13:56:51 -0400 (EDT)
So the buttonpress type callbacks (that take GdkEvent *) should return a
true or a false depending on whether or not I want the default actions to
take place, correct?
By the way, how does the marshalling function know what my function
returns? Some sort of a pre-processor trick?
Thanks!
Pavel
On Wed, 16 Jun 1999, Joshua Richardson wrote:
> > This is part C part GTK question.
> > How can bot, f(GtkWidget *, gpointer) and g(GtkWidget *, GdkEvent *,
> > gpointer) be cast to GdkSignalFunc which is typedefed to look like neither
> > of the above but f()? Is that even legal from the point of view of C?
>
> >From C's point of view, a function is a pointer (to a piece of code.)
> In C you can explicitly cast any pointer to any other pointer type, but
> the onus is on you to make sure that such wild casting doesn't get you
> into trouble. This is one of the main reasons some people hate C.
>
> > Also, how are GtkSignalFunc's made use of internally? Also, it lookes like
> > the latter kind is expected by GTK to return and int, but I define mine as
> > void. Yet, nothing crashes. So how does all this work?
>
> Each widget "knows" about its signals, and what kind of callbacks will be
> attached to them. This was accomplished in Gtk by associating each signal
> with a "marshalling" function, which is the function that actually calls
> your callback, and will do so with an appropriate set of arguments. It's
> your job to make sure that your function (that you always cast to the
> generic GtkSignalFunc type) will handle the arguments delivered by the
> marshalling function. The event related marshalling functions check for a
> return value from your callback, as explained in the tutorial. So, if
> your function isn't returning a value (as a void function won't), then the
> marshalling function is getting a random value "returned". This, of
> course, may or may not cause problems, depending on context, but obviously
> should be avoided. :-)
>
> > Pavel
>
> Hope that helps (and is correct ;-)), --josh
>
> ----------------------------------------------------------------
> Joshua Richardson
> Dept. Cognitive and Neural Systems / Center for Adaptive Systems
> Boston University
> ----------------------------------------------------------------
>
>
>
> --
> To unsubscribe: mail -s unsubscribe gtk-list-request@redhat.com < /dev/null
>
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]