--- Paolo Borelli <[EMAIL PROTECTED]> wrote: > > > > *** > ../../glade3.orig/src/glade-signal-editor.c > > > Mon > > > > Jan 12 21:38:09 2004 > > > > --- glade-signal-editor.c Mon Jan 12 > > > 22:04:06 > > > > 2004 > > > > *************** > > > > *** 158,161 **** > > > > --- 158,162 ---- > > > > GtkTreeIter *parent = NULL; > > > > GList *list = NULL; > > > > + GtkTreePath *path_first = NULL; > > > > GladeWidgetClassSignal *signal; > > > > > > > > > > No need to initialize local vars to NULL as far > as I > > > can see, while you > > > are at it remove it also from the other vars; > > > beside, not related to > > > your code, but usually a TreeIter is allocated > on > > > the stack: i.e. > > > GtkTreeIter iter; > > > gtk_tree_functio (..., &iter, ...); > > > > > > > I don't understand. > > > About the variables declaration you can omit the "= > NULL;". > > About the treeiter: I took a closer look at the code > and in this case I > have to admit the using a pointer to the iter is > correct since > glade_signal_editor_dialog_append_signal returns a > iter allocated in the > heap memory with g_new0. Not your fault, but as far > as I can see this > memory is leaked since there isn't a g_free (iter). > > In general, if you look at the docs in gtk you'll > see that most of the > times, even if the iter is an object, it is used as > a local variable, > not as a pointer: i.e. GtkTreeIter iter; this means > that the memory for > the object is automatically allocated on the stack > when the function is > called and automatically freed when the function > ends. Of course since > some of the API need to get a pointer to iter, you > pass them the var > address, i.e. &iter. > In our case using this approach would mean modify > the > glade_signal_editor_dialog_append_signal function to > take another iter > pointer as parameter instead of returning a newly > allocated iter, and > pass &parent to it. > > Hope this clear things a bit.
Oh! I got the problem. I should have used gtk_tree_model_get_iter_first, instead of the one I used before. > > > > *************** > > > > *** 183,186 **** > > > > --- 188,193 ---- > > > > gint response; > > > > > > > > + g_assert(editor); > > > > + g_assert(editor->class); > > > > g_return_if_fail > (editor->class->signals > > > != > > > > NULL); > > > > > > > > > > Use g_return_if_fail instead of assert to check > > > function args. > > > > No. If you have seen my bug report on glade3, > the > > program actually segfaults. But with these assert > > statement, it shows the correct message as 'assert > > failure', saving minutes of fiddling up with gdb. > > Any thoughts? > > > > g_return_if_fail *are* asserts made exactly for this > use; when they fail > they print a critical message on the console and > then return so that the > function is not executed. But without the above two g_assert statements, the statement g_return_if_fail (editor->class->signals); _will_ cause segfault, if either `editor` or `class` is NULL! > > ciao > paolo > ===== Sridhar R Email: [EMAIL PROTECTED] WWW: http://sridhar.has.it __________________________________ Do you Yahoo!? Yahoo! Hotjobs: Enter the "Signing Bonus" Sweepstakes http://hotjobs.sweepstakes.yahoo.com/signingbonus _______________________________________________ Glade-devel maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/glade-devel
