[vtkusers] Subclassing vtkActor broken?

[stoptv]

On 4/18/06, Marc Cotran <marc at cotran.ca> wrote:
>
> I'm still not sure exactly what you are trying to do by subclassing
> vtkActor, but have you considered making a wrapper class instead? I mean
> something like:
>
> class Pigment
> {
> public:
>     Pigment();
>
> private:
>     vtkActor *internalActor;
> }
>
> In most cases this type of class should be fine, but if not, please let
> me know why you absolutely need to derive from vtkActor, and then we can
> tackle the invisibility issue.
>

hi,

well I'd really like some polymorphic action here.. if I was able to have a
Pigment that is a  vtkActor
I'd be able to use a picker to click around my objects in an elegant way.

ie. a picker returns an Actor, i check if it's a Pigment and then just do a
p->mixThisPigment(result);

(this is just one example.. there are many other things i'd like my pigments
to do)

As it is I have to push all of my actors through an if-then-else-if oredeal
that I don't really like.
I don't think I can evade that by wrapping Actors in a class.

suggestions are always welcome!! thanks again :-)

--
stoptv at gmail.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.vtk.org/pipermail/vtkusers/attachments/20060418/a2513cb5/attachment.htm>