Yeah, multi-threading sounds like an unnecessary complication here. I wanted to
say this already on your previous message. Why don't you just add depending
changes to the same ChangeOperation as I have outlines before - if isBusy()
then just do the changes directly, not wrapped in a IChange. Only create a new
IChange if no other one is currently open.
But without details and spending a lot of time (difficult for me, sorry) it is
hard to help.
Holger
On Apr 28, 2010, at 6:46 PM, Andriy Sokolov wrote:
> Hello Holger!
>
>> Therefore I make now an extra thread, where there are an
>> infinite loop 'while (TB.getSession().ChangeEngine.isBusy()){}' and
>> thereafter 'TB.getSession().getChangeEngine().execute(IChange)'. Now
>> everything works perfectly. Thank You wery much!
>
> after some tests I found out that my solution has a problem: the undo
> behaviour is unstable. in 95% of cases it works fine, but sometimes
> one of complex changes "goes lost" (by one simply action it does never
> happen), so I can redo all graph IChanges except one. Do You have a
> proposal what could be a reason? May be it is an issue of the thread
> safety?
>
> Thanks,
> Andriy
>
> --
> You received this message because you are subscribed to the Google
> Group "TopBraid Suite Users", the topics of which include TopBraid Composer,
> TopBraid Live, TopBraid Ensemble, SPARQLMotion and SPIN.
> To post to this group, send email to
> [email protected]
> To unsubscribe from this group, send email to
> [email protected]
> For more options, visit this group at
> http://groups.google.com/group/topbraid-users?hl=en
--
You received this message because you are subscribed to the Google
Group "TopBraid Suite Users", the topics of which include TopBraid Composer,
TopBraid Live, TopBraid Ensemble, SPARQLMotion and SPIN.
To post to this group, send email to
[email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/topbraid-users?hl=en
