[Insight-developers] RE: Abort and minipipelines

[Miller, James V (Research)]

The only disadvantage is that it will require people to 
write "persistent" mini-pipelines.  I.e. the pipelines
will have to be ivars of the class as opposed to local
variables in the GenerateData() method.

If the filter writer doesn't want to keep the pipeline
as ivars, they could use and observer on the progress event
of the filters in the mini-pipeline and call SetAbortGenerateData()
on the mini-pipeline filter in the progress callback if the 
its own AbortGenerateData flag is set. It would be nice if
we had a nice example of this that people could pattern.


Jim

> -----Original Message-----
> From: Luis Ibanez [mailto:luis.ibanez@kitware.com]
> Sent: Tuesday, April 08, 2003 1:29 PM
> To: Miller, James V (Research); Insight Developers List
> Subject: Abort and minipipelines
> 
> 
> Hi Jim,
> 
> Here is another tweak in the process of stopping
> filter execution.
> 
> Filters containing minipipelines don't have
> currently a way of notifying their internal
> pipeline that the user has cancel the execution.
> 
> It seems that the SetAbortGenerataData() method
> will have to be overloaded in these filters
> in order to propagate the flag setting to the
> internal filters.
> 
> An alternative could be to use Events/Observers,
> but it will be hard to ensure that the filters
> in the minipipeline will be notified of the
> AbortEvent before anybody else....
> 
> 
> Do you see any disadvantages in overloading
> SetAbortGenerateData()   ?
> 
> 
> Thanks
> 
> 
> 
>   Luis
> 
>