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