Re: Destroying widgets properly

Me too.

	My framework is libs_apps_YEAR-MM_DD.tgz at
	The gtk code is in src/lib_base2/gtk_1/

	I think I fixed my problem by realising that GTK destroys its
	own widget, THEN tells with the "destroy" callback, so that
	C++ can release its storage WITHOUT REFERRING TO GTK

	The GTK widget object's memory has been free()d, but you are
	still using it, which either reports "not a valid object",
	or corrupts indirect memory, and the program trips up LATER.

	When an upper container is deleted, its children get AUTO deleted,
	so you must avoid deleting them, but delete the C++ objects.

	I also had an issue with signal_disconnect_by_data().
	I'd claim it still happens, but have stopped calling it (leak).


	An alternative phase I went through, was when C++ deleted its
	object, when the GTK object is fully alive.

	Then GTK calls back, with the deleted objects pointer
	... chaos ...

-Different ways-

	Different designs require opposite senses. Should your code
	delete the widget before or after GTK? Do you tell it, or
	does it tell you?

	Reference counts can split widget deconstruction into
	two halves. The DISPLAYED widgets reduction to a skeleton,
	and later free(widget), with the C++ objects delete somewhere.

	I do tend to NOT do a refcount on GTK objects, even though I keep
	a pointer to them. My excuse is that I should not have received
	a "1" count in the first place, which gets absorbed by the PACK
	action (ASIDE check how TCL does this - it's magically sensible,
	and NOT how Python does it). So I do nothing (and it now works).

   Information-Cascade (at)

> Message: 1
> Date: Sun, 18 Jan 2004 00:42:46 -0800
> From: The Surprises <thesurprises1 comcast net>
> To: gtk-list gnome org
> Subject: Destroying widgets properly
> Hello,
> I am getting mysterious and inconsistent crashes in my gtk program
> (ie it isn't crashing in the same spot every time), and
> I believe it has something to do with how I am destroying a set of
> widgets.  I have an hbox (HB) packed into a vbox (VB).  HB has many
> widgets packed inside of it, most of which are also created/maintained
> in their own C++ classes.  One of the widgets is a GnomeCanvas, and it
> itself has many GnomeCanvasItem children, nearly each maintained in
> seperate C++ classes as well.  At times, I need to entirely remove HB
> and all of it's children including the canvas and all of it's children.
> I then recreate everything from scratch and pack into VB.  Actually the
> destroy seems to work OK.  It is when I try to recreate all the widgets
> that I get the core dump.
> I tried having each class destructor first delete it's children (with a
> 'delete'), then destroy it's own widget (in the case of the
> GnomeCanvasItems, using GTK_OBJECT_DESTROY and casting the CanvasItem).
> I thought this made the most sense since you want to delete the children
> first before you delete the parent or you'll have children pointing to
> parents that no longer exist.  I also tried reversing the order as well
> but get the same result.  I get error messages like this:
> GLib-GObject-WARNING **: invalid uninstantiatable type
> `gint64' in cast to `GtkObject'
> Gtk-CRITICAL **: file gtkobject.c: line 358
> (gtk_object_destroy): assertion `GTK_IS_OBJECT (object)' failed
> GLib-GObject-WARNING **: invalid cast from `(null)' to
> `GtkObject'
> Gtk-CRITICAL **: file gtkobject.c: line 358
> (gtk_object_destroy): assertion `GTK_IS_OBJECT (object)' failed
> I tried just doing a destroy on HB but get the same results.  It seems
> like I'm leaving something behind.  It works a few times, then crashes.
> Or it crashes on the first try. 
> Thanks for any help
> Jason
> --__--__--
> _______________________________________________
> gtk-list mailing list
> gtk-list gnome org
> End of gtk-list Digest

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