Re: [pygtk] canvas item callbacks

2002-05-21 Thread Stephen Langer
Thanks for the help earlier on callbacks from canvas items. Now I have another related problem. Within my callback, python exception notices are being repressed. The exceptions are occuring, but python isn't telling me about them, which makes tracking down bugs extremely painful. As you might

Re: [pygtk] canvas item callbacks

2002-05-21 Thread Christian Reis
On Tue, May 21, 2002 at 09:38:12AM -0400, Stephen Langer wrote: As you might recall, I'm getting mouse events in C++ for canvas items from a gtk-canvas object. The C++ callback calls a Python function, sandwiching a call to PyEval_CallObject between calls to PyGtk_BlockThreads and

Re: [pygtk] canvas item callbacks

2002-05-21 Thread Stephen Langer
Thanks for the suggestions... I've found the problem. I was being sloppy with the return value from PyObject_CallObject. -- Steve On Tue, May 21, 2002 at 10:53:34AM -0300, Christian Reis wrote: On Tue, May 21, 2002 at 09:38:12AM -0400, Stephen Langer wrote: As you might recall, I'm

Re: [pygtk] canvas item callbacks

2002-05-15 Thread Stephen Langer
On Tue, May 14, 2002 at 07:22:52PM -0700, Mathew Yeates wrote: Hmmm, I've run across this also. It turned out that I needed to create a shared library. If the original file is foo.c, compile it to foo.o then create a shared object called foo.so with ld -shared foo.o -o foo.so. Then it won't

Re: [pygtk] canvas item callbacks

2002-05-15 Thread James Henstridge
Stephen Langer wrote: On Tue, May 14, 2002 at 07:22:52PM -0700, Mathew Yeates wrote: Hmmm, I've run across this also. It turned out that I needed to create a shared library. If the original file is foo.c, compile it to foo.o then create a shared object called foo.so with ld -shared foo.o -o

Re: [pygtk] canvas item callbacks

2002-05-15 Thread Mathew Yeates
I just went and looked at my code (its a plugin for SciGraphica). I DO NOT define NO_IMPORT and this causes your missing symbol to be defined in pygtk.h. As for init_pygtk, I never call it! But I'm importing gtk prior to loading my module. Mathew We are creating a shared library, with

Re: [pygtk] canvas item callbacks

2002-05-15 Thread Stephen Langer
On Thu, May 16, 2002 at 12:30:42AM +0800, James Henstridge wrote: In one of the source files for your module you must not define NO_IMPORT_PYGTK (all others, you should define it). You would then need to copy the contents of the init_pygtk() macro to your code and fix the C++ cast

Re: [pygtk] canvas item callbacks

2002-05-15 Thread James Henstridge
Stephen Langer wrote: On Thu, May 16, 2002 at 12:30:42AM +0800, James Henstridge wrote: In one of the source files for your module you must not define NO_IMPORT_PYGTK (all others, you should define it). You would then need to copy the contents of the init_pygtk() macro to your code and

[pygtk] canvas item callbacks

2002-05-14 Thread Stephen Langer
I'm encountering some strange behavior and hope someone on this list can provide some insight. We're using pygtk 0.6.8 with python 2.1, and gtk-canvas 0.1. We're using the gtk-canvas instead of gnome-canvas so that our users don't have to install all of gnome. A disadvantage of that is that

Re: [pygtk] canvas item callbacks

2002-05-14 Thread Mathew Yeates
I'm going to make a wild ass guess here. Have you tried inserting the macros to block threads? Can't remember exactly what they are but I've seen tons of examples in the pygtk code. Mathew I'm encountering some strange behavior and hope someone on this list can provide some insight. We're

Re: [pygtk] canvas item callbacks

2002-05-14 Thread Stephen Langer
On Tue, May 14, 2002 at 04:10:14PM -0700, Mathew Yeates wrote: I'm going to make a wild ass guess here. Have you tried inserting the macros to block threads? Can't remember exactly what they are but I've seen tons of examples in the pygtk code. Mathew For a wild ass guess, that was

Re: [pygtk] canvas item callbacks

2002-05-14 Thread Mathew Yeates
Hmmm, I've run across this also. It turned out that I needed to create a shared library. If the original file is foo.c, compile it to foo.o then create a shared object called foo.so with ld -shared foo.o -o foo.so. Then it won't mind the undefined symbol (which gets loaded at run time) Mathew