Re: Memory dealocation using "destroy" signal /callback



El Lun 20 May 2002 04:02, Paul Davis escribió:
> >I'm building my  own wdgets, most of them , uses dinamic allocated memory
> > and I need to make sure that this memory is deallocated when the widtget
> > is destroyed.
> >
> >I would like to know what is best. replace the GtkObject destroy function
> > or use a signal conecting "destroy" GtkObject Widget.
> >
> >Anyway I need to know about the destroy process.
> >I can understand who make the call to the destroy function.
> >
> >
> >I have tested this code, drawing my new widget.
> >but de destroy funcion on my widget seems to be never called.
>
> your program will never result in the execution of destroy handlers.
> gtk_main_quit() does not clean up after itself. Havoc (forgive me if I
> misquote you Havoc) has said that GTK has not been written with the
> idea that you could finish using GTK but have your program run some
> more. its assumed that a top level gtk_main_quit() is shortly followed
> by program exit, when the OS cleans up after your process no matter
> what your process did. you cannot assume that after gtk_main_quit(),
> things are as they were before gtk_init().

Yes is what I suposed. 
>
> if you want the destroy handler called, remove the widget from its
> container and call gtk_widget_destroy() on it; alternatively, leave it
> in the container and destroy the container, which has assumed
> ownership (i.e. responsibility) for the widgets it contains. the
> simple story: a widget is only destroyed when its reference count
> reaches zero. that will never happen in your program.

Well this code was a single test, the widget will be used on more complex 
apps. Anyway what is best ? , should I use the signal or callback ? for 
redefine my destroy handler ??. 


Thanks.

>
> --p

-- 
=================
Toni Moreno Giménez
=================
Pje de las rosas  nº 22
Vilassar de Mar 
(Barcelona) España
CP: 08340
-----------------
Tel:937598149
Tel: 699706656
-----------------



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