[this refers to trunk of OpenSG2]
Hi,
I'm a bit confused about what the correct semantics for application of a
changelist to another aspect should be. I was under the impression
that this should not cause entries in the applying threads CL in order
to allow syncing back and forth between two aspects.
Now, in 2 with the CL having two roles at once (keeping track of which
containers need their changed method called and recording changes to be
applied to other aspects) I am not sure if this transitivity (or better
lack thereof) is correctly maintained.
More precisely, I believe syncing from aspect A to aspect B should cause
_uncommitedChanges entries to be created in the CL of the thread that
applies the changes, but it should not put them into _changedStore
(which AFAICS happens now, because FieldContainer::execSync calls
FieldContainer::editSField, calls
FieldContainer::registerChangedContainer, calls ChangeList::getNewEntry,
which always does a push_back to _changedStore).
A similar thing happens with the {add|sub}Ref CL entries, as they are
handled by calling FieldContainer::{add|sub}Reference which always
creates new CL entries.
Did I get the basic premise of CLs being explicitly NOT transitive
wrong, or is there an implementation error lurking in this code ?
Thanks,
Carsten
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Opensg-core mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/opensg-core
