On Thu, Aug 19, 2004 at 01:21:33PM +0200, Leopold Toetsch wrote: > [ segfaulting example ] > > g_signal_connect_object (G_OBJECT (button), "clicked", > > G_CALLBACK (hello), NULL, 0); > > Are you sure, that these two G_foo() aren't doing something with the > function arguments? These are just typecasts/checks actually, so you can remove them and it will still work (youll receive a warning though when compiling it but otherwise it will work without problems - have tried it).
> I've beautified the example a bit, segfaults much nicer now ;)
Cool, thanks for that :), Ill go through the sdl examples as
well to get on more pir.
> Dunno, what's wrong.
Just built a "debugable" version of gtk, so as to see whats going on
when it enters this function. Mainly its "button" param, as well as
its "user_data" are not set (or at least ddd doesnt know how to give
me any info about it), but it breaks "because of its user data"..
g_signal_connect_object (gpointer instance,
const gchar *detailed_signal,
GCallback c_handler,
gpointer gobject,
GConnectFlags connect_flags)
{
g_return_val_if_fail (G_TYPE_CHECK_INSTANCE (instance), 0);
g_return_val_if_fail (detailed_signal != NULL, 0);
g_return_val_if_fail (c_handler != NULL, 0);
if (gobject)
{
GClosure *closure;
>>>> g_return_val_if_fail (G_IS_OBJECT (gobject), 0); <<<< Fails here
anyway I just dont see what could be wrong with the way parrot could be
passing the "user_data"?
Whats the difference between the way parrot calls this, and the way
the C example is doing it? As the parrot example follows exactly the
same steps as the C one.
What ddd can tell me is:
[instance] ? disableb
[detailed_signal] = "clicked"
[c_handler] = Parrot_callback_C
[gobject] ? disabled
[connect_flags] = 0
> leo
Thanks,
Stephane
gobject.c.gz
Description: GNU Zip compressed data
