Re: Memory dealocation using "destroy" signal /callback



>> 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 ??. 

you're mixing terminology in a confusing way. GTK signals are the name
given to a complex, though easy to use, callback system. you don't
have a choice between signals and callbacks. your handler is fine,
even though it does nothing right now. the problem is simply that
nothing ever calls gtk_widget_destroy(). 

if you want to test the handler, do as i suggested above. its rare
that applications need to worry about the destroy signal, unless they
have frequently constructed widgets that are associated with large
chunks of per-widget-private data. if so, perhaps it matters, but you
might be wise to read up on Model-View-Controller programming as a
different and much more flexible and correct program design technique.

--p



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