John Ehresman wrote:
[EMAIL PROTECTED] wrote:
Michael> is there a way to trap gtk assertions in pygtk?
None that I'm aware of. I believe I've asked about this before as
well. It
would be *really* nice if these got translated into Python exceptions by
PyGTK.
They are routed through the python warnings module so you can log them
to a file or stop in them in a debugger. You can't really turn them
into exceptions, though -- this could theoretically be added in some
cases (maybe), but it's a fair amount of work.
The bigger problem is that a fair amount of C code doesn't handle the
case where the assertion fails -- e.g. a call may be made to create a
window & fails on an assert, but the next line assumes the window has
been created and dereferences a pointer. Trapping this is the same
problem as trapping errors in buggy C code. It's better to avoid
failing on the assertion in the first place.
John
This latter problem is causing my core dumps. Fortunately, there is a
simple way to suppress access to previously destroyed Gtk objects, by
wrapping the using e.g.
class GtkObjProxy:
def __init__(self, obj):
self._obj = obj
self._live = True
obj.connect("destroy", self._destroyed)
def __getattr__(self, nm):
if self._live:
return self._obj.__getattribute__(nm)
else:
raise Exception("Accessing dead gtk object.")
def _destroyed(self, widget):
self._live = False
and then using
foo = GtkObjProxy( <construct> )
instead of just
foo = <construct>
This avoids the core dumps, and allows me to examine the program state
via pdb.
That leaves only the problem of writing correct code in the first
place...
Cheers,
Mike
_______________________________________________
pygtk mailing list [email protected]
http://www.daa.com.au/mailman/listinfo/pygtk
Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/
