You should be able to do the conversion without casting. Perhaps you are missing an #include <vesActor.h> so that the compiler knows vesActor is a subclass of vesNode? This line should compile:<br><br>vesSharedPtr<vesNode> node = rep->actor();<br>
<br>Also, if you do need to cast, for example to go from vesNode down to vesActor, this is the proper way to do it:<br><br>vesSharedPtr<vesActor> actor = std::tr1::dynamic_pointer_cast<vesActor>(node);<br><br>
(or use static_pointer_cast if you prefer)<br><br>Also, note that vesNode::Ptr is equivalent to vesSharedPtr<vesNode> and it can save you some extra characters :)<br><br>Pat<br><br><div class="gmail_quote">On Tue, Feb 19, 2013 at 3:05 PM, Eduardo Poyart <span dir="ltr"><<a href="mailto:poyart@gmail.com" target="_blank">poyart@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Pat,<br>
<br>
Thank you for the quick reply. Indeed it was not a const problem, it<br>
was a problem with the types wrapped in shared pointers. I managed to<br>
find a way to coerce the types. This is my old code:<br>
<br>
vesSharedPtr<vesActor> actor = vesSharedPtr<vesActor>(rep->actor());<br>
transform->addChild(actor);<br>
<br>
The compiler fails with the following error: "cannot initialize a<br>
member subobject of type 'vesNode *' with an lvalue of type 'vesActor<br>
*const'".<br>
<br>
I changed it to:<br>
<br>
vesSharedPtr<vesNode> actor =<br>
vesSharedPtr<vesNode>((vesNode*)rep->actor().get());<br>
transform->addChild(actor);<br>
<br>
This compiles fine. Hopefully I'm not leaking memory or anything! :)<br>
<br>
Thanks<br>
<span class="HOEnZb"><font color="#888888">Eduardo<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
<br>
<br>
On Mon, Feb 18, 2013 at 7:13 PM, Pat Marion <<a href="mailto:pat.marion@kitware.com">pat.marion@kitware.com</a>> wrote:<br>
> Hi,<br>
><br>
> Hmm, are you sure about that? The get actor method on<br>
> vesKiwiPolyDataRepresentation should look like this:<br>
><br>
> vesSharedPtr<vesActor> actor() const;<br>
><br>
> So the returned pointer is not const. Did you mean the sceneRoot() method<br>
> on vesRenderer?<br>
><br>
> The reason for the code comment you saw, it's actually an old comment, at<br>
> the time the VES api was being heavily refactored, so client code that used<br>
> the ves objects would break, the kiwi class attempts to be a convenience<br>
> layer that would sheild client code from the api changes. At this point the<br>
> VES api has stabilized, so I no longer have plans to move those methods to<br>
> be protected.<br>
><br>
> Pat<br>
><br>
><br>
><br>
> On Tue, Feb 19, 2013 at 12:14 PM, Eduardo Poyart <<a href="mailto:poyart@gmail.com">poyart@gmail.com</a>> wrote:<br>
>><br>
>> Hi Pat,<br>
>><br>
>> Answering your question about my ImageWidgetRepresentation, I have<br>
>> modified vesKiwiImageWidgetRepresentation to apply a few filters to the<br>
>> dataset, and to change the contour level set value in real time.<br>
>><br>
>> Now that I have a more well-defined ImageWidgetRepresentation, I have<br>
>> another question.<br>
>><br>
>> I'm modifying the sample to show two models, with independent translations<br>
>> and rotations. The ideal solution is to add a vesTransformNode to the root<br>
>> node, instead of adding the actors directly to root. It would be great to<br>
>> use this sene-graph convenience.<br>
>><br>
>> However, the actual adding to root is done in vesRenderer::addActor. So<br>
>> instead I thought I could get the root node with vesRenderer::sceneRoot()<br>
>> and add the actors. The problem is that, from vesKiwiPolyDataRepresentation,<br>
>> I can only get a const actor. Furthermore, to my dismay, there is a comment<br>
>> in vesKiwiPolyDataRepresentation saying that actor() will be moved to<br>
>> protected in the future, therefore making this class even more inflexible.<br>
>><br>
>> It's not a clean solution to use the Actor's built-in transformation. One<br>
>> vesKiwiWidgetRepresentation contains multiple internal representations<br>
>> (image planes, contour, frame). So, I would have to create loops to set the<br>
>> same transform to the various actors.<br>
>><br>
>> On the other hand, if I subclass vesKiwiPolyDataRepresentation, I can't<br>
>> access Actor since it's in the Internal section. Entirely copying the<br>
>> vesKiwiPolyDataRepresentation and modifying it would be even more<br>
>> undesirable.<br>
>><br>
>> If you have any solution, I would appreciate the suggestion. For now, I<br>
>> think I'll end up manually setting up all of the Actor's transformations. I<br>
>> hope my use-case explanation is useful for further development of ves!<br>
>><br>
>> Thanks<br>
>> Eduardo<br>
>><br>
>><br>
>> On Tue, Feb 12, 2013 at 7:57 PM, Pat Marion <<a href="mailto:pat.marion@kitware.com">pat.marion@kitware.com</a>><br>
>> wrote:<br>
>>><br>
>>> Hi Eduardo,<br>
>>><br>
>>> You're correct that the vesKiwiViewerApp api is insufficient. There's a<br>
>>> branch called kiwi-update which has a new version of the code which adds<br>
>>> methods to access the internal representations, and add new ones to the<br>
>>> list. You could use this branch, or modify your copy of vesKiwiViewerApp.<br>
>>> The kiwi-update branch has a lot of changes to it though, so if don't want<br>
>>> the disruption then I would recommend you just modify vesKiwiViewerApp to<br>
>>> add accessors to the internal representations vector.<br>
>>><br>
>>> But, you might be interested in some of the changes, there are new<br>
>>> features to the existing image widget class<br>
>>> vesKiwiImageWidgetRepresentation. I'd be interested to hear from you if you<br>
>>> want to share what you are doing with your ImageWidgetRepresentation class,<br>
>>> and if you have any suggestions for improvements to the<br>
>>> vesKiwiWidgetRepresentation base class. Thanks!<br>
>>><br>
>>> Pat<br>
>>><br>
>>> On Wed, Feb 13, 2013 at 9:43 AM, Eduardo Poyart <<a href="mailto:poyart@gmail.com">poyart@gmail.com</a>> wrote:<br>
>>>><br>
>>>> Hello,<br>
>>>><br>
>>>> I extended vesKiwiViewerApp with my own subclass ViewerApp. I also<br>
>>>> needed to create a new representation, which I called<br>
>>>> ImageWidgetRepresentation, extending from vesKiwiWidgetRepresentation.<br>
>>>><br>
>>>> I wrote a custom load routine in ViewerApp, and now I need to add the<br>
>>>> data to Internal, with something like:<br>
>>>><br>
>>>> this->Internal->DataRepresentations.push_back(rep);<br>
>>>><br>
>>>> However this can't be done since vesKiwiViewerApp.Internal is private.<br>
>>>> What is the correct design pattern in this case?<br>
>>>><br>
>>>> Thanks<br>
>>>> Eduardo<br>
>>>><br>
>>>><br>
>>>><br>
>>>><br>
>>>> _______________________________________________<br>
>>>> Ves mailing list<br>
>>>> <a href="mailto:Ves@public.kitware.com">Ves@public.kitware.com</a><br>
>>>> <a href="http://public.kitware.com/cgi-bin/mailman/listinfo/ves" target="_blank">http://public.kitware.com/cgi-bin/mailman/listinfo/ves</a><br>
>>>><br>
>>><br>
>><br>
><br>
</div></div></blockquote></div><br>