[Insight-developers] Managing Abort in Filters

[Miller, James V (Research)]

Also, by having the filter catch the exception first, it may be 
able to produce a "subset" of the output.  This subset may be 
useful to the user.

A "good" example of this (as opposed to something completely hokey)
is that the user may run a registration algorithm then click "stop", 
adjust some parameters, and run another algorithm starting where the 
last one left off.

Jim


> -----Original Message-----
> From: Joshua Cates [mailto:cates@sci.utah.edu]
> Sent: Tuesday, April 08, 2003 1:59 PM
> To: Luis Ibanez
> Cc: Insight Developers List
> Subject: Re: [Insight-developers] Managing Abort in Filters
> 
> 
> Yes, this makes sense.
> 
> Josh.
> 
> 
> On Tue, 8 Apr 2003, Luis Ibanez wrote:
> 
> > Hi Josh,
> > 
> > Yeap, at the end of the day the user (or the GUI)
> > has to deal with the exception. The application
> > should be prepared for this since the Abort command
> > was actually originated from the user/GUI.
> > 
> > The only reason for catching in the GenerateData()
> > method is for potentially relase memory that has been
> > allocated locally. Once this cleanning is done, the
> > exception is thrown again.
> > 
> > 
> >    Luis
> > 
> > 
> > --------------------
> > 
> > Joshua Cates wrote:
> > > Hi Luis,
> > > 
> > > Why not have the user handle this exception?  If a filter 
> is aborted then
> > > it cannot produce a correct output and the user must then 
> decide how to
> > > proceed.
> > > 
> > > Josh.
> > > 
> > 
> > _______________________________________________
> > Insight-developers mailing list
> > Insight-developers@public.kitware.com
> > http://public.kitware.com/mailman/listinfo/insight-developers
> > 
> 
> _______________________________________________
> Insight-developers mailing list
> Insight-developers@public.kitware.com
> http://public.kitware.com/mailman/listinfo/insight-developers
>