Thanks for the advice. Looks like ChangeList::setReadOnly() does the trick if used properly. I was having trouble before because of other strange problems in my code. - Terry
On 2/8/06, Gerrit Voss <[EMAIL PROTECTED]> wrote: > > Hi, > > On Wed, 2006-02-08 at 11:45 -0700, Dirk Reiners wrote: > > Hi Terry, > > > > On Tue, 2006-02-07 at 09:51 -0600, Terry Welsh wrote: > > > bump > > > > > > Since I wrote this post I have experimented with using > > > ChangeList::setReadOnly when modifying the non-connected graph. This > > > definitely has an effect, but I have not been able to make it work > > > cleanly or completely. Is this even the right approach? > > > > Probably not, but I need to understant better what's going on. > > > > > On 1/27/06, Terry Welsh <[EMAIL PROTECTED]> wrote: > > > > I have two separate plugins (dlls #1 and #2) running underneath the > > > > same 3rd party application, each containing its own complete OpenSG > > > > graph. The graph in dll #1 is connected to another computer via > > > > RemoteAspect. When I make changes to the non-connected graph in dll > > > > #2, the changes are seen and transmitted by the connected graph in dll > > > > #1. > > > > > > > > Would this be due to resource sharing by OpenSG since both graphs are > > > > running underneath the same executable? Is there any way to prevent > > > > this? > > > > What are the changes that you see having effects? If they are separate > > graphs (i.e. separate root nodes) there shouldn't be any interaction > > between them, no matter whether they're in the same dll or not. I could > > see interaction on Materials, depending on how stuff is loaded and > > processed though, and maybe via Prototypes, but you shouldn't touch > > those in a regular app. > > they are connected through the same aspect, hence the same changelist. > Which means that any change done by the app (on the graph of #1 and #2) > is transmitted. In effect transmitting the graph from dll #2 to the > remote aspect. > > I have puzzled about it a little bit but the changelist approach seems > to be the most promising one right now. The problem is that we separate > things by thread, within one thread we have no good measure of filtering > things before sending, especially for 1.6. And creating multiple threads > to solve the problems seems to be a little bit overkill and not so easy > to do. > > Terry could you give me a rough idea what is behind 'cleanly or > completely' ? > > For the future a good idea might be something similar to namespaces and > a simple filtering mechanism based on this information. But I haven't > thought this through. > > regards, > gerrit > > > > > > > ------------------------------------------------------- > This SF.net email is sponsored by: Splunk Inc. Do you grep through log files > for problems? Stop! Download the new AJAX search engine that makes > searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! > http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642 > _______________________________________________ > Opensg-users mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/opensg-users > ------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnk&kid3432&bid#0486&dat1642 _______________________________________________ Opensg-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/opensg-users
