Hi Andreas,
Andreas Halm wrote:
>
> I was first missing documentation about how to write your own node (or core)
> class when using opensg 1.8, and now I am missing it again while converting
> from 1.8 to 2.0. So this post should encourage anybody capable of doing so
> to write a chapter about it J
You're right, that is a part that we need to document.
> Specific information I am missing is:
>
> - What are the methods absolutely needed to get it going, and what
> is their purpose
>
> - What are:
>
> o static ClassTransitPtr create();
> o static Class* createEmpty();
> o static ClassTransitPtr createLocal(BitVector bFlags = FCLocal::All);
> o static Class* createEmptyLocal(BitVector bFlags =
> FCLocal::All);
> o static ClassTransitPtr createDependent(BitVector bFlags);
> o virtual FieldContainerTransitPtr shallowCopy () const;
> o virtual FieldContainerTransitPtr shallowCopyLocal(BitVector bFlags =
> FCLocal::All) const;
> o virtual FieldContainerTransitPtr shallowCopyDependent(BitVector bFlags)
> const;
> o virtual FieldContainer* createAspectCopy(const FieldContainer
> *pRefAspect) const;
>
> for, and in which cases would you need implementations different from the
> usual ones
Gerrit gave the details, but just to make it clear: we *strongly* warn against
copy-n-pasting to generate your FCs. Use the .fcd mechanism! That's is a much,
much easier way, as there are just too many side dependencies that you do not
want to mess with (like the list above), especially if things need to be
extended or changed on the inside.
We do not give any guarantees that the internal structure of FC does not
change.
We do guarantee that the fcds you write now will continue to work (until OpenSG
3, which will hopefully be far, far into the future ;).
> - What the hell happened to beginEditCP/endEditCP
Gone for good (yippiie! ;). Just forget about them. All you do need to do is
call commitChanges() (or commitChangesAndClear()) after you're done creating a
block of objects for your graph (or, a little more concretely, when you switch
from writing to reading from FCs).
> - What exactly do you need to enable synchronization
In general, nothing.
As long as you have a standard FC, which uses our standard fieldtypes. Sync
only
comes into play when you start defining your own datatypes, but that's a
different story.
> A minimalistic implementation of a node, carefully documented, would be
> really nice and would make my life so much easier.
In 1.8 we had the Cubes example to show how to write your own OpenGL-rendering
NodeCore. An example for simple FCs, including and most interestingly for
adding
sync-compatible new types, was in Examples/NewTypes. Carsten, do you think
you'll have some time in the next few days to port these?
Yours
Dirk
------------------------------------------------------------------------------
Crystal Reports - New Free Runtime and 30 Day Trial
Check out the new simplified licensing option that enables unlimited
royalty-free distribution of the report engine for externally facing
server and web deployment.
http://p.sf.net/sfu/businessobjects
_______________________________________________
Opensg-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/opensg-users
