RE: [CPP] Storing data in a compileOp

["Helge Mathee" <Helge_Mathee(at)Softimage.COM>]

use a cstringarray and push the fullname into it everytime you add an operator.

corresponding to this array there should be an array of structs to store your

custom data.

 

so when you want to look up the data just loop through the stringarray and

compare the fullname to the value in the array. the index of the matching string

is the index of the structure of the op.

---

From: owner-xsi(at)Softimage.COM [mailto:owner-xsi(at)Softimage.COM] On Behalf Of Alan Jones
Sent: Monday, December 12, 2005 10:16 AM
To: XSI(at)Softimage.COM
Subject: Re: [CPP] Storing data in a compileOp

Hi Andrew,

Could you elaborate on the data structure mapping? 
:-)

Thanks,

Alan.

On 12/12/05, Andrew Skowronski < askowron(at)softimage.com> wrote:

You have some flexibility in C++ to share data between your commands and operators, providing you are careful about

the possibility of there being multiple instances of a particular operator and understanding their life time (Init/Term and Load/Save into Scene files)

 

For example you could have a data structure that maps from the full name of the operator to its data, so that both commands and operators

can look up the data associated with an operator.

 

It could also be possible to use events to store some additional information into the scene (e.g. in a user data blob) so that the operator

doesn't need to directly read and write a user data blob but that the data is persisted.

 

Hope this helps,

 

-Andrew

 

-----Original Message-----
From: owner-xsi(at)Softimage.COM [mailto:owner-xsi(at)Softimage.COM]On Behalf Of Alan Jones
Posted At: Monday, December 12, 2005 10:00 AM
Posted To: xsi
Conversation: [CPP] Storing data in a compileOp
Subject: Re: [CPP] Storing data in a compileOp

hehe just realised after my last long reply I still forgot why. It's not a real necessity - it's just so that if I wanted to reposition the constrained object I could do it without removing and recreating the constraint. Though I'm not too concerned as with the current plan it'll be pretty quick to remove and reapply anyway.

Cheers,

Alan.

On 12/12/05, Guy Rabiller <guy(at)alamaison.fr> wrote:

> Now you sound like Luc-Eric :-)

Oo! Please, tell me you are kidding! :p

> ../.. Operator to operator connection comes to mind ../..

When I'm asking Alan why he would do that, it's not for me to imply he
must not, but just to understand the 'design' of his tool - or his
approach - because most of the time there is a better way than to start
hacking dll or create odd pipes. ;-)
--
guy rabiller | 3d technical director (at) LaMaison



Felix Gebhardt a écrit :

>
> Now you sound like Luc-Eric :-)
>
> Operator to operator connection comes to mind. The fact that one can't
> store data with the operator instance to be conveniently grabbed from
> somewhere else is a major bummer. See Syflex implementation for an
> example of how much hassle is involved.
>
> Not that I'm greedy and would ask for persistent operator data that is
> automatically stored with the scene, just a little pointer storage
> space would do.
>
> F.
>
> Guy Rabiller schrieb:
>
>> I meant why would you want to call the function from outside of your
>> Class/Operator ?
>>
>>
> ---
> Unsubscribe? Mail Majordomo(at)Softimage.COM with the following text in
> body:
> unsubscribe xsi
>
>


---
Unsubscribe? Mail Majordomo(at)Softimage.COM with the following text in body:
unsubscribe xsi