[vtk-developers] setting AbortFlag from Python impossible?

David Gobbi david.gobbi at gmail.com
Thu Sep 20 15:31:02 EDT 2007


On 9/20/07, Charl Botha <c.p.botha at tudelft.nl> wrote:
> Hi Berk and David,
>
> On 9/20/07, Berk Geveci <berk.geveci at kitware.com> wrote:
> > Oops. I forgot that vtkCommand is sub-classes from vtkObjectBase...
> > Errr.... Ok, now that I finally understand the issue, I vote in favor
> > of Charl's solution.
>
> Aah, thanks for answering that bit David, I should have read the whole
> thread before explaining that bit again.
>
> David, returning a special value as you suggest adds even more code to
> that bit of vtkPythonUtil.  Is there something against returning an
> integer, for now taking >= 1 as meaning that the event has been
> handled and event processing should stop, and 0 meaning that the
> observer has not completely handled the event and wants processing to
> continue?

One reason to use a special object is to avoid backwards-incompatibility
issues.  I'm fairly sure that most of the callback methods that I use now
are returning None but I can't guarantee. without doing a full review
of all the python/vtk code that I use, that some of my callbacks aren't
already returning ints...

My concern here is that most VTK-Python users are going to be totally
unaware that the return value of a callback means anything at all.  If they
happen to have a callback that does "return 1" somewhere (for example
if they cut-and-pasted some of their callback code from a different function)
then it'll take them forever to figure out why their callback doesn't work
like it used to.

An explicit "return vtk.AbortCallback" makes the code so much more
explicit and easy to understand...  The "AbortCallback" object can be
as simple as a python string with "AbortCallback" as its contents.

 David



More information about the vtk-developers mailing list