Home » Eclipse Projects » GEF » Retargeted connections problem
| Retargeted connections problem [message #129284] |
Wed, 28 April 2004 05:24  |
Eclipse User |
|
|
|
Originally posted by: cwhite.ic.net
I have a diagram where when a specific edit part refreshes, existing
connections are targeted to new child edit parts and some old edit parts
that were targets of the same connections are deleted. When the children are
refreshed the connections are properly stiched to the new edit parts.
However, the old edit parts are then deleted (in the refreshChildren method)
and the connection target is set to null.
So the connections end up no target. Is there a way to avoid this behavior?
|
|
|
| Re: Retargeted connections problem [message #129348 is a reply to message #129284] |
Wed, 28 April 2004 17:50  |
| Eclipse User |
|
|
|
Originally posted by: cwhite.ic.net
I thought I should give a better explanation of this problem.
Say I have an diagram edit part that has two children with a connection
between them.
[X]----C--->[Y]
So now the model changes and X now connects to Z instead of Y (Y is gone):
The model behind the connection part is the same model object.
[X]----C--->[Z]
When the diagram is refreshed the new edit part for Z is created and the C
connection edit part has its target set to Z. The refreshChildren method
then removes the unneeded edit part for Y. As part of the removal it sets
the target of C to null. So the connection ends up pointing to nowhere.
There is probably something I should be doing to avoid this problem but I
don't know what it is. For now, I have had to override removeNotify to get
around the problem. Basically, the edit part only sets the source or target
of the connection to null if it is the current source or target.
public void removeNotify()
{
List conns;
conns = getSourceConnections();
while (conns.size() > 0) {
ConnectionEditPart cep = (ConnectionEditPart)conns.get(0);
if (cep.getSource() == this) {
cep.setSource(null);
} else {
fireRemovingSourceConnection(cep,
getSourceConnections().indexOf(cep));
primRemoveSourceConnection(cep);
}
}
conns = getTargetConnections();
while (conns.size() > 0)
{
ConnectionEditPart cep = (ConnectionEditPart)conns.get(0);
if (cep.getTarget() == this) {
cep.setTarget(null);
} else {
fireRemovingTargetConnection(cep,
getTargetConnections().indexOf(cep));
primRemoveTargetConnection(cep);
}
}
super.removeNotify();
}
}
"Chris White" <cwhite@ic.net> wrote in message
news:c6nci8$tno$1@eclipse.org...
> I have a diagram where when a specific edit part refreshes, existing
> connections are targeted to new child edit parts and some old edit parts
> that were targets of the same connections are deleted. When the children
are
> refreshed the connections are properly stiched to the new edit parts.
> However, the old edit parts are then deleted (in the refreshChildren
method)
> and the connection target is set to null.
>
> So the connections end up no target. Is there a way to avoid this
behavior?
>
>
|
|
| |
| Re: Retargeted connections problem [message #129662 is a reply to message #129438] |
Thu, 29 April 2004 10:43 |
| Eclipse User |
|
|
|
Originally posted by: cwhite.ic.net
Thank you for the response.
In this particular case, the diagram is reacting to resource changes in the
workspace. So I have to handle everything in the refresh of the diagram. The
user is not executing commands to modify the model.
Is there any chance you could modify AbstractEditPart.removeNotify() to see
if the edit part is the source/target of the connection before nulling this
property? This would solve this problem and seems like a reasonable change.
Should I create a bug report?
"Pratik Shah" <ppshah@us.ibm.com> wrote in message
news:c6p27q$2ga$1@eclipse.org...
> Hmm, it looks like all the ties between the connection and the old target
> are not being severed when the connection is re-targeted. I was not able
to
> reproduce this problem in the logic example. Re-targetting an existing
> connection (manually), and then deleting the old target works just fine
> there. You might want to check to see what you're doing differently from
> the logic example. The ConnectionCommand in the logic example detaches
the
> old target first (thus severing all ties) in its execute() method. Make
> sure you are doing the same.
>
>
> "Chris White" <cwhite@ic.net> wrote in message
> news:c6on47$l2c$1@eclipse.org...
> > I thought I should give a better explanation of this problem.
> >
> > Say I have an diagram edit part that has two children with a connection
> > between them.
> >
> > [X]----C--->[Y]
> >
> > So now the model changes and X now connects to Z instead of Y (Y is
gone):
> > The model behind the connection part is the same model object.
> >
> > [X]----C--->[Z]
> >
> > When the diagram is refreshed the new edit part for Z is created and the
C
> > connection edit part has its target set to Z. The refreshChildren method
> > then removes the unneeded edit part for Y. As part of the removal it
sets
> > the target of C to null. So the connection ends up pointing to nowhere.
> >
> > There is probably something I should be doing to avoid this problem but
I
> > don't know what it is. For now, I have had to override removeNotify to
get
> > around the problem. Basically, the edit part only sets the source or
> target
> > of the connection to null if it is the current source or target.
> > public void removeNotify()
> > {
> > List conns;
> > conns = getSourceConnections();
> >
> >
> > while (conns.size() > 0) {
> > ConnectionEditPart cep = (ConnectionEditPart)conns.get(0);
> > if (cep.getSource() == this) {
> > cep.setSource(null);
> > } else {
> > fireRemovingSourceConnection(cep,
> > getSourceConnections().indexOf(cep));
> > primRemoveSourceConnection(cep);
> > }
> > }
> >
> >
> > conns = getTargetConnections();
> > while (conns.size() > 0)
> > {
> > ConnectionEditPart cep = (ConnectionEditPart)conns.get(0);
> > if (cep.getTarget() == this) {
> > cep.setTarget(null);
> > } else {
> > fireRemovingTargetConnection(cep,
> > getTargetConnections().indexOf(cep));
> > primRemoveTargetConnection(cep);
> > }
> > }
> >
> >
> > super.removeNotify();
> >
> > }
> >
> > }
> >
> >
> > "Chris White" <cwhite@ic.net> wrote in message
> > news:c6nci8$tno$1@eclipse.org...
> > > I have a diagram where when a specific edit part refreshes, existing
> > > connections are targeted to new child edit parts and some old edit
parts
> > > that were targets of the same connections are deleted. When the
children
> > are
> > > refreshed the connections are properly stiched to the new edit parts.
> > > However, the old edit parts are then deleted (in the refreshChildren
> > method)
> > > and the connection target is set to null.
> > >
> > > So the connections end up no target. Is there a way to avoid this
> > behavior?
> > >
> > >
> >
> >
>
>
|
|
|
| Re: Retargeted connections problem [message #129759 is a reply to message #129348] |
Thu, 29 April 2004 15:49 |
| Eclipse User |
|
|
|
Originally posted by: none.us.ibm.com
The problem is that you are refreshing (reconciling) the children, but you
are not reconciling the connections properly. At some point in your
execution and model notification, you have said that Z is the target of C,
at the same time that Y is the target of Z. Connections are managed by
their nodes in GEF. So we currently require that a node release its link to
a connection before another node assumes the same link (whether source or
target). Most models should work the same way. If you have modeled the
connections similarly (multiplicity of 1), then a connection can only have a
single target. When it's target is set to something new, it should go to
its old target an unhook itself. This is the way EMF bidirectional
reference work. And their notification, even if it is batched, will come in
the correct order which reflects the changes made in the model.
What are the specifics of your model and how it notifies to editparts?
During this resource change, why don't you just reload the entire diagram?
"Chris White" <cwhite@ic.net> wrote in message
news:c6on47$l2c$1@eclipse.org...
> I thought I should give a better explanation of this problem.
>
> Say I have an diagram edit part that has two children with a connection
> between them.
>
> [X]----C--->[Y]
>
> So now the model changes and X now connects to Z instead of Y (Y is gone):
> The model behind the connection part is the same model object.
>
> [X]----C--->[Z]
>
> When the diagram is refreshed the new edit part for Z is created and the C
> connection edit part has its target set to Z. The refreshChildren method
> then removes the unneeded edit part for Y. As part of the removal it sets
> the target of C to null. So the connection ends up pointing to nowhere.
>
> There is probably something I should be doing to avoid this problem but I
> don't know what it is. For now, I have had to override removeNotify to get
> around the problem. Basically, the edit part only sets the source or
target
> of the connection to null if it is the current source or target.
> public void removeNotify()
> {
> List conns;
> conns = getSourceConnections();
>
>
> while (conns.size() > 0) {
> ConnectionEditPart cep = (ConnectionEditPart)conns.get(0);
> if (cep.getSource() == this) {
> cep.setSource(null);
> } else {
> fireRemovingSourceConnection(cep,
> getSourceConnections().indexOf(cep));
> primRemoveSourceConnection(cep);
> }
> }
>
>
> conns = getTargetConnections();
> while (conns.size() > 0)
> {
> ConnectionEditPart cep = (ConnectionEditPart)conns.get(0);
> if (cep.getTarget() == this) {
> cep.setTarget(null);
> } else {
> fireRemovingTargetConnection(cep,
> getTargetConnections().indexOf(cep));
> primRemoveTargetConnection(cep);
> }
> }
>
>
> super.removeNotify();
>
> }
>
> }
>
>
> "Chris White" <cwhite@ic.net> wrote in message
> news:c6nci8$tno$1@eclipse.org...
> > I have a diagram where when a specific edit part refreshes, existing
> > connections are targeted to new child edit parts and some old edit parts
> > that were targets of the same connections are deleted. When the children
> are
> > refreshed the connections are properly stiched to the new edit parts.
> > However, the old edit parts are then deleted (in the refreshChildren
> method)
> > and the connection target is set to null.
> >
> > So the connections end up no target. Is there a way to avoid this
> behavior?
> >
> >
>
>
|
|
|
| Re: Retargeted connections problem [message #129817 is a reply to message #129759] |
Thu, 29 April 2004 18:20 |
| Eclipse User |
|
|
|
Originally posted by: cwhite.ic.net
Randy,
Here is what's happening in our application:
We open our diagam/editor and set its contents based on the state of a
number of resources. At this point Y is a target of C.
The user then makes a modification to some resources (e.g. changes the
target of C so that it points to Z and deletes Y). All of these changes can
happen outside our editor. Our editor is notified of the change and attempts
the refresh. The refreshChildren method detects the new model object Z and
gets its connections. It also knows that the old edit part has to be
deleted. So at this point, both the model and the edit parts/connections are
correct. The only thing left is the cleanup of the deleted edit parts.
But as you pointed out, the old edit part still exists and still knows about
its source and target connections. When it cleans up the old edit part it
sets the target of the connection to null.
It seems reasonable to me that the edit part should not set the source/targt
to null if the source/target are not the edit part.
We do reload the entire diagram. We listen for
IResourceChangeEvent.POST_AUTO_BUILD event then reload the diagram. Since
the model for the connection is often the same model object, this edit part
is not recreated.
"Randy Hudson" <none@us.ibm.com> wrote in message
news:c6r7qs$dq1$1@eclipse.org...
> The problem is that you are refreshing (reconciling) the children, but you
> are not reconciling the connections properly. At some point in your
> execution and model notification, you have said that Z is the target of C,
> at the same time that Y is the target of Z. Connections are managed by
> their nodes in GEF. So we currently require that a node release its link
to
> a connection before another node assumes the same link (whether source or
> target). Most models should work the same way. If you have modeled the
> connections similarly (multiplicity of 1), then a connection can only have
a
> single target. When it's target is set to something new, it should go to
> its old target an unhook itself. This is the way EMF bidirectional
> reference work. And their notification, even if it is batched, will come
in
> the correct order which reflects the changes made in the model.
>
> What are the specifics of your model and how it notifies to editparts?
> During this resource change, why don't you just reload the entire diagram?
>
> "Chris White" <cwhite@ic.net> wrote in message
> news:c6on47$l2c$1@eclipse.org...
> > I thought I should give a better explanation of this problem.
> >
> > Say I have an diagram edit part that has two children with a connection
> > between them.
> >
> > [X]----C--->[Y]
> >
> > So now the model changes and X now connects to Z instead of Y (Y is
gone):
> > The model behind the connection part is the same model object.
> >
> > [X]----C--->[Z]
> >
> > When the diagram is refreshed the new edit part for Z is created and the
C
> > connection edit part has its target set to Z. The refreshChildren method
> > then removes the unneeded edit part for Y. As part of the removal it
sets
> > the target of C to null. So the connection ends up pointing to nowhere.
> >
> > There is probably something I should be doing to avoid this problem but
I
> > don't know what it is. For now, I have had to override removeNotify to
get
> > around the problem. Basically, the edit part only sets the source or
> target
> > of the connection to null if it is the current source or target.
> > public void removeNotify()
> > {
> > List conns;
> > conns = getSourceConnections();
> >
> >
> > while (conns.size() > 0) {
> > ConnectionEditPart cep = (ConnectionEditPart)conns.get(0);
> > if (cep.getSource() == this) {
> > cep.setSource(null);
> > } else {
> > fireRemovingSourceConnection(cep,
> > getSourceConnections().indexOf(cep));
> > primRemoveSourceConnection(cep);
> > }
> > }
> >
> >
> > conns = getTargetConnections();
> > while (conns.size() > 0)
> > {
> > ConnectionEditPart cep = (ConnectionEditPart)conns.get(0);
> > if (cep.getTarget() == this) {
> > cep.setTarget(null);
> > } else {
> > fireRemovingTargetConnection(cep,
> > getTargetConnections().indexOf(cep));
> > primRemoveTargetConnection(cep);
> > }
> > }
> >
> >
> > super.removeNotify();
> >
> > }
> >
> > }
> >
> >
> > "Chris White" <cwhite@ic.net> wrote in message
> > news:c6nci8$tno$1@eclipse.org...
> > > I have a diagram where when a specific edit part refreshes, existing
> > > connections are targeted to new child edit parts and some old edit
parts
> > > that were targets of the same connections are deleted. When the
children
> > are
> > > refreshed the connections are properly stiched to the new edit parts.
> > > However, the old edit parts are then deleted (in the refreshChildren
> > method)
> > > and the connection target is set to null.
> > >
> > > So the connections end up no target. Is there a way to avoid this
> > behavior?
> > >
> > >
> >
> >
>
>
|
|
|
| Re: Retargeted connections problem [message #129830 is a reply to message #129759] |
Thu, 29 April 2004 18:31 |
| Eclipse User |
|
|
|
Originally posted by: cwhite.ic.net
Randy,
I just realized your post suggests another solution. It sounds like you are
suggesting that I override AbstractConnectionEditPart.setTarget(...) so that
it unhooks from the current target of the connection. I am assuming that I
would do this by calling primRemoveSourceConnection().
Is this what you were suggesting?
"Randy Hudson" <none@us.ibm.com> wrote in message
news:c6r7qs$dq1$1@eclipse.org...
> The problem is that you are refreshing (reconciling) the children, but you
> are not reconciling the connections properly. At some point in your
> execution and model notification, you have said that Z is the target of C,
> at the same time that Y is the target of Z. Connections are managed by
> their nodes in GEF. So we currently require that a node release its link
to
> a connection before another node assumes the same link (whether source or
> target). Most models should work the same way. If you have modeled the
> connections similarly (multiplicity of 1), then a connection can only have
a
> single target. When it's target is set to something new, it should go to
> its old target an unhook itself. This is the way EMF bidirectional
> reference work. And their notification, even if it is batched, will come
in
> the correct order which reflects the changes made in the model.
>
> What are the specifics of your model and how it notifies to editparts?
> During this resource change, why don't you just reload the entire diagram?
>
> "Chris White" <cwhite@ic.net> wrote in message
> news:c6on47$l2c$1@eclipse.org...
> > I thought I should give a better explanation of this problem.
> >
> > Say I have an diagram edit part that has two children with a connection
> > between them.
> >
> > [X]----C--->[Y]
> >
> > So now the model changes and X now connects to Z instead of Y (Y is
gone):
> > The model behind the connection part is the same model object.
> >
> > [X]----C--->[Z]
> >
> > When the diagram is refreshed the new edit part for Z is created and the
C
> > connection edit part has its target set to Z. The refreshChildren method
> > then removes the unneeded edit part for Y. As part of the removal it
sets
> > the target of C to null. So the connection ends up pointing to nowhere.
> >
> > There is probably something I should be doing to avoid this problem but
I
> > don't know what it is. For now, I have had to override removeNotify to
get
> > around the problem. Basically, the edit part only sets the source or
> target
> > of the connection to null if it is the current source or target.
> > public void removeNotify()
> > {
> > List conns;
> > conns = getSourceConnections();
> >
> >
> > while (conns.size() > 0) {
> > ConnectionEditPart cep = (ConnectionEditPart)conns.get(0);
> > if (cep.getSource() == this) {
> > cep.setSource(null);
> > } else {
> > fireRemovingSourceConnection(cep,
> > getSourceConnections().indexOf(cep));
> > primRemoveSourceConnection(cep);
> > }
> > }
> >
> >
> > conns = getTargetConnections();
> > while (conns.size() > 0)
> > {
> > ConnectionEditPart cep = (ConnectionEditPart)conns.get(0);
> > if (cep.getTarget() == this) {
> > cep.setTarget(null);
> > } else {
> > fireRemovingTargetConnection(cep,
> > getTargetConnections().indexOf(cep));
> > primRemoveTargetConnection(cep);
> > }
> > }
> >
> >
> > super.removeNotify();
> >
> > }
> >
> > }
> >
> >
> > "Chris White" <cwhite@ic.net> wrote in message
> > news:c6nci8$tno$1@eclipse.org...
> > > I have a diagram where when a specific edit part refreshes, existing
> > > connections are targeted to new child edit parts and some old edit
parts
> > > that were targets of the same connections are deleted. When the
children
> > are
> > > refreshed the connections are properly stiched to the new edit parts.
> > > However, the old edit parts are then deleted (in the refreshChildren
> > method)
> > > and the connection target is set to null.
> > >
> > > So the connections end up no target. Is there a way to avoid this
> > behavior?
> > >
> > >
> >
> >
>
>
|
|
|
| Re: Retargeted connections problem [message #129944 is a reply to message #129817] |
Thu, 29 April 2004 22:17 |
| Eclipse User |
|
|
|
Originally posted by: none.us.ibm.com
"Chris White" <cwhite@ic.net> wrote in message
news:c6rd84$ko7$1@eclipse.org...
> Randy,
>
> Here is what's happening in our application:
>
> We open our diagam/editor and set its contents based on the state of a
> number of resources. At this point Y is a target of C.
>
> The user then makes a modification to some resources (e.g. changes the
> target of C so that it points to Z and deletes Y). All of these changes
can
> happen outside our editor. Our editor is notified of the change and
attempts
> the refresh. The refreshChildren method detects the new model object Z and
> gets its connections. It also knows that the old edit part has to be
> deleted. So at this point, both the model and the edit parts/connections
are
> correct.
I would argue that the connections are not correct. Y should have called
refreshTargetEditParts prior to Z's becoming the target of the connection.
Even though Y is going to be deleted, you haven't deleted it yet, so it is
still the target. A similar scenario is reparenting. The old editpart in
the old parent must be deleted before the new editpart (for the same model
object) is created in the new parent. Otherwise, connection will break
there too.
> The only thing left is the cleanup of the deleted edit parts.
>
> But as you pointed out, the old edit part still exists and still knows
about
> its source and target connections. When it cleans up the old edit part it
> sets the target of the connection to null.
>
> It seems reasonable to me that the edit part should not set the
source/targt
> to null if the source/target are not the edit part.
Possibly, or AbstractConnectionEditPart.setTarget(EditPart) could throw an
exception if you are overwriting the existing target, which should have
removed itself.
> We do reload the entire diagram. We listen for
> IResourceChangeEvent.POST_AUTO_BUILD event then reload the diagram. Since
> the model for the connection is often the same model object, this edit
part
> is not recreated.
>
> "Randy Hudson" <none@us.ibm.com> wrote in message
> news:c6r7qs$dq1$1@eclipse.org...
> > The problem is that you are refreshing (reconciling) the children, but
you
> > are not reconciling the connections properly. At some point in your
> > execution and model notification, you have said that Z is the target of
C,
> > at the same time that Y is the target of Z. Connections are managed by
> > their nodes in GEF. So we currently require that a node release its
link
> to
> > a connection before another node assumes the same link (whether source
or
> > target). Most models should work the same way. If you have modeled the
> > connections similarly (multiplicity of 1), then a connection can only
have
> a
> > single target. When it's target is set to something new, it should go
to
> > its old target an unhook itself. This is the way EMF bidirectional
> > reference work. And their notification, even if it is batched, will
come
> in
> > the correct order which reflects the changes made in the model.
> >
> > What are the specifics of your model and how it notifies to editparts?
> > During this resource change, why don't you just reload the entire
diagram?
> >
> > "Chris White" <cwhite@ic.net> wrote in message
> > news:c6on47$l2c$1@eclipse.org...
> > > I thought I should give a better explanation of this problem.
> > >
> > > Say I have an diagram edit part that has two children with a
connection
> > > between them.
> > >
> > > [X]----C--->[Y]
> > >
> > > So now the model changes and X now connects to Z instead of Y (Y is
> gone):
> > > The model behind the connection part is the same model object.
> > >
> > > [X]----C--->[Z]
> > >
> > > When the diagram is refreshed the new edit part for Z is created and
the
> C
> > > connection edit part has its target set to Z. The refreshChildren
method
> > > then removes the unneeded edit part for Y. As part of the removal it
> sets
> > > the target of C to null. So the connection ends up pointing to
nowhere.
> > >
> > > There is probably something I should be doing to avoid this problem
but
> I
> > > don't know what it is. For now, I have had to override removeNotify to
> get
> > > around the problem. Basically, the edit part only sets the source or
> > target
> > > of the connection to null if it is the current source or target.
> > > public void removeNotify()
> > > {
> > > List conns;
> > > conns = getSourceConnections();
> > >
> > >
> > > while (conns.size() > 0) {
> > > ConnectionEditPart cep = (ConnectionEditPart)conns.get(0);
> > > if (cep.getSource() == this) {
> > > cep.setSource(null);
> > > } else {
> > > fireRemovingSourceConnection(cep,
> > > getSourceConnections().indexOf(cep));
> > > primRemoveSourceConnection(cep);
> > > }
> > > }
> > >
> > >
> > > conns = getTargetConnections();
> > > while (conns.size() > 0)
> > > {
> > > ConnectionEditPart cep = (ConnectionEditPart)conns.get(0);
> > > if (cep.getTarget() == this) {
> > > cep.setTarget(null);
> > > } else {
> > > fireRemovingTargetConnection(cep,
> > > getTargetConnections().indexOf(cep));
> > > primRemoveTargetConnection(cep);
> > > }
> > > }
> > >
> > >
> > > super.removeNotify();
> > >
> > > }
> > >
> > > }
> > >
> > >
> > > "Chris White" <cwhite@ic.net> wrote in message
> > > news:c6nci8$tno$1@eclipse.org...
> > > > I have a diagram where when a specific edit part refreshes, existing
> > > > connections are targeted to new child edit parts and some old edit
> parts
> > > > that were targets of the same connections are deleted. When the
> children
> > > are
> > > > refreshed the connections are properly stiched to the new edit
parts.
> > > > However, the old edit parts are then deleted (in the refreshChildren
> > > method)
> > > > and the connection target is set to null.
> > > >
> > > > So the connections end up no target. Is there a way to avoid this
> > > behavior?
> > > >
> > > >
> > >
> > >
> >
> >
>
>
|
|
|
| Re: Retargeted connections problem [message #129956 is a reply to message #129830] |
Thu, 29 April 2004 22:18 |
| Eclipse User |
|
|
|
Originally posted by: none.us.ibm.com
You need to be careful or you connection will be activated twice, and you
will have listener leaks.
"Chris White" <cwhite@ic.net> wrote in message
news:c6rdrt$lgf$1@eclipse.org...
> Randy,
>
> I just realized your post suggests another solution. It sounds like you
are
> suggesting that I override AbstractConnectionEditPart.setTarget(...) so
that
> it unhooks from the current target of the connection. I am assuming that I
> would do this by calling primRemoveSourceConnection().
>
> Is this what you were suggesting?
>
> "Randy Hudson" <none@us.ibm.com> wrote in message
> news:c6r7qs$dq1$1@eclipse.org...
> > The problem is that you are refreshing (reconciling) the children, but
you
> > are not reconciling the connections properly. At some point in your
> > execution and model notification, you have said that Z is the target of
C,
> > at the same time that Y is the target of Z. Connections are managed by
> > their nodes in GEF. So we currently require that a node release its
link
> to
> > a connection before another node assumes the same link (whether source
or
> > target). Most models should work the same way. If you have modeled the
> > connections similarly (multiplicity of 1), then a connection can only
have
> a
> > single target. When it's target is set to something new, it should go
to
> > its old target an unhook itself. This is the way EMF bidirectional
> > reference work. And their notification, even if it is batched, will
come
> in
> > the correct order which reflects the changes made in the model.
> >
> > What are the specifics of your model and how it notifies to editparts?
> > During this resource change, why don't you just reload the entire
diagram?
> >
> > "Chris White" <cwhite@ic.net> wrote in message
> > news:c6on47$l2c$1@eclipse.org...
> > > I thought I should give a better explanation of this problem.
> > >
> > > Say I have an diagram edit part that has two children with a
connection
> > > between them.
> > >
> > > [X]----C--->[Y]
> > >
> > > So now the model changes and X now connects to Z instead of Y (Y is
> gone):
> > > The model behind the connection part is the same model object.
> > >
> > > [X]----C--->[Z]
> > >
> > > When the diagram is refreshed the new edit part for Z is created and
the
> C
> > > connection edit part has its target set to Z. The refreshChildren
method
> > > then removes the unneeded edit part for Y. As part of the removal it
> sets
> > > the target of C to null. So the connection ends up pointing to
nowhere.
> > >
> > > There is probably something I should be doing to avoid this problem
but
> I
> > > don't know what it is. For now, I have had to override removeNotify to
> get
> > > around the problem. Basically, the edit part only sets the source or
> > target
> > > of the connection to null if it is the current source or target.
> > > public void removeNotify()
> > > {
> > > List conns;
> > > conns = getSourceConnections();
> > >
> > >
> > > while (conns.size() > 0) {
> > > ConnectionEditPart cep = (ConnectionEditPart)conns.get(0);
> > > if (cep.getSource() == this) {
> > > cep.setSource(null);
> > > } else {
> > > fireRemovingSourceConnection(cep,
> > > getSourceConnections().indexOf(cep));
> > > primRemoveSourceConnection(cep);
> > > }
> > > }
> > >
> > >
> > > conns = getTargetConnections();
> > > while (conns.size() > 0)
> > > {
> > > ConnectionEditPart cep = (ConnectionEditPart)conns.get(0);
> > > if (cep.getTarget() == this) {
> > > cep.setTarget(null);
> > > } else {
> > > fireRemovingTargetConnection(cep,
> > > getTargetConnections().indexOf(cep));
> > > primRemoveTargetConnection(cep);
> > > }
> > > }
> > >
> > >
> > > super.removeNotify();
> > >
> > > }
> > >
> > > }
> > >
> > >
> > > "Chris White" <cwhite@ic.net> wrote in message
> > > news:c6nci8$tno$1@eclipse.org...
> > > > I have a diagram where when a specific edit part refreshes, existing
> > > > connections are targeted to new child edit parts and some old edit
> parts
> > > > that were targets of the same connections are deleted. When the
> children
> > > are
> > > > refreshed the connections are properly stiched to the new edit
parts.
> > > > However, the old edit parts are then deleted (in the refreshChildren
> > > method)
> > > > and the connection target is set to null.
> > > >
> > > > So the connections end up no target. Is there a way to avoid this
> > > behavior?
> > > >
> > > >
> > >
> > >
> >
> >
>
>
|
|
|
| Re: Retargeted connections problem [message #132489 is a reply to message #129944] |
Mon, 17 May 2004 22:13 |
| Eclipse User |
|
|
|
Originally posted by: cwhite.ic.net
One more try here and then I will give up.
I have run into this problem again with another model.
In this model, the links are managed by a parent model object. The child
model objects don't know about the links. We are using edit parts to make
the connection by asking the parent model object for the appropriate
connections.
When we retarget a connection, we simply change the model link to reflect
the correct connection. Of course, we run to a problem when GEF removes the
connection edit part from the old source/target.
Again, this would all work fine if the connection edit part did not set its
source/target to null if the source/target is not the edit part that is
removing the connection.
Going into begging mode: Please, oh please, can you make this change?
"Randy Hudson" <none@us.ibm.com> wrote in message
news:c6ruh1$8nv$1@eclipse.org...
>
> "Chris White" <cwhite@ic.net> wrote in message
> news:c6rd84$ko7$1@eclipse.org...
> > Randy,
> >
> > Here is what's happening in our application:
> >
> > We open our diagam/editor and set its contents based on the state of a
> > number of resources. At this point Y is a target of C.
> >
> > The user then makes a modification to some resources (e.g. changes the
> > target of C so that it points to Z and deletes Y). All of these changes
> can
> > happen outside our editor. Our editor is notified of the change and
> attempts
> > the refresh. The refreshChildren method detects the new model object Z
and
> > gets its connections. It also knows that the old edit part has to be
> > deleted. So at this point, both the model and the edit parts/connections
> are
> > correct.
> I would argue that the connections are not correct. Y should have called
> refreshTargetEditParts prior to Z's becoming the target of the connection.
> Even though Y is going to be deleted, you haven't deleted it yet, so it is
> still the target. A similar scenario is reparenting. The old editpart in
> the old parent must be deleted before the new editpart (for the same model
> object) is created in the new parent. Otherwise, connection will break
> there too.
>
> > The only thing left is the cleanup of the deleted edit parts.
> >
> > But as you pointed out, the old edit part still exists and still knows
> about
> > its source and target connections. When it cleans up the old edit part
it
> > sets the target of the connection to null.
> >
> > It seems reasonable to me that the edit part should not set the
> source/targt
> > to null if the source/target are not the edit part.
>
> Possibly, or AbstractConnectionEditPart.setTarget(EditPart) could throw an
> exception if you are overwriting the existing target, which should have
> removed itself.
>
> > We do reload the entire diagram. We listen for
> > IResourceChangeEvent.POST_AUTO_BUILD event then reload the diagram.
Since
> > the model for the connection is often the same model object, this edit
> part
> > is not recreated.
> >
> > "Randy Hudson" <none@us.ibm.com> wrote in message
> > news:c6r7qs$dq1$1@eclipse.org...
> > > The problem is that you are refreshing (reconciling) the children, but
> you
> > > are not reconciling the connections properly. At some point in your
> > > execution and model notification, you have said that Z is the target
of
> C,
> > > at the same time that Y is the target of Z. Connections are managed
by
> > > their nodes in GEF. So we currently require that a node release its
> link
> > to
> > > a connection before another node assumes the same link (whether source
> or
> > > target). Most models should work the same way. If you have modeled
the
> > > connections similarly (multiplicity of 1), then a connection can only
> have
> > a
> > > single target. When it's target is set to something new, it should go
> to
> > > its old target an unhook itself. This is the way EMF bidirectional
> > > reference work. And their notification, even if it is batched, will
> come
> > in
> > > the correct order which reflects the changes made in the model.
> > >
> > > What are the specifics of your model and how it notifies to editparts?
> > > During this resource change, why don't you just reload the entire
> diagram?
> > >
> > > "Chris White" <cwhite@ic.net> wrote in message
> > > news:c6on47$l2c$1@eclipse.org...
> > > > I thought I should give a better explanation of this problem.
> > > >
> > > > Say I have an diagram edit part that has two children with a
> connection
> > > > between them.
> > > >
> > > > [X]----C--->[Y]
> > > >
> > > > So now the model changes and X now connects to Z instead of Y (Y is
> > gone):
> > > > The model behind the connection part is the same model object.
> > > >
> > > > [X]----C--->[Z]
> > > >
> > > > When the diagram is refreshed the new edit part for Z is created and
> the
> > C
> > > > connection edit part has its target set to Z. The refreshChildren
> method
> > > > then removes the unneeded edit part for Y. As part of the removal it
> > sets
> > > > the target of C to null. So the connection ends up pointing to
> nowhere.
> > > >
> > > > There is probably something I should be doing to avoid this problem
> but
> > I
> > > > don't know what it is. For now, I have had to override removeNotify
to
> > get
> > > > around the problem. Basically, the edit part only sets the source or
> > > target
> > > > of the connection to null if it is the current source or target.
> > > > public void removeNotify()
> > > > {
> > > > List conns;
> > > > conns = getSourceConnections();
> > > >
> > > >
> > > > while (conns.size() > 0) {
> > > > ConnectionEditPart cep = (ConnectionEditPart)conns.get(0);
> > > > if (cep.getSource() == this) {
> > > > cep.setSource(null);
> > > > } else {
> > > > fireRemovingSourceConnection(cep,
> > > > getSourceConnections().indexOf(cep));
> > > > primRemoveSourceConnection(cep);
> > > > }
> > > > }
> > > >
> > > >
> > > > conns = getTargetConnections();
> > > > while (conns.size() > 0)
> > > > {
> > > > ConnectionEditPart cep = (ConnectionEditPart)conns.get(0);
> > > > if (cep.getTarget() == this) {
> > > > cep.setTarget(null);
> > > > } else {
> > > > fireRemovingTargetConnection(cep,
> > > > getTargetConnections().indexOf(cep));
> > > > primRemoveTargetConnection(cep);
> > > > }
> > > > }
> > > >
> > > >
> > > > super.removeNotify();
> > > >
> > > > }
> > > >
> > > > }
> > > >
> > > >
> > > > "Chris White" <cwhite@ic.net> wrote in message
> > > > news:c6nci8$tno$1@eclipse.org...
> > > > > I have a diagram where when a specific edit part refreshes,
existing
> > > > > connections are targeted to new child edit parts and some old edit
> > parts
> > > > > that were targets of the same connections are deleted. When the
> > children
> > > > are
> > > > > refreshed the connections are properly stiched to the new edit
> parts.
> > > > > However, the old edit parts are then deleted (in the
refreshChildren
> > > > method)
> > > > > and the connection target is set to null.
> > > > >
> > > > > So the connections end up no target. Is there a way to avoid this
> > > > behavior?
> > > > >
> > > > >
> > > >
> > > >
> > >
> > >
> >
> >
>
>
|
|
|
| Re: Retargeted connections problem [message #132821 is a reply to message #132489] |
Tue, 18 May 2004 22:18 |
| Eclipse User |
|
|
|
Originally posted by: none.us.ibm.com
We have made this change for you, but one more try and I will give up too.
The notification is happening out of order, even in this new case you
present. Some parent object holds all connections, which have a source and
target property. When you overwrite one of these properties, you should
first notify the old node that it is no longer the source of the connection,
and it will call refresh..., then notify the new node.
A similar scenario is adding a figure to a new parent. Even though you do
not first remove the figure from its previous parent, there is no time at
which you can find the figure in both old and new parent's children Arrays.
I believe the notification is also consistent.
"Chris White" <cwhite@ic.net> wrote in message
news:c8b9li$75e$1@eclipse.org...
> One more try here and then I will give up.
>
> I have run into this problem again with another model.
>
> In this model, the links are managed by a parent model object. The child
> model objects don't know about the links. We are using edit parts to make
> the connection by asking the parent model object for the appropriate
> connections.
>
> When we retarget a connection, we simply change the model link to reflect
> the correct connection. Of course, we run to a problem when GEF removes
the
> connection edit part from the old source/target.
>
> Again, this would all work fine if the connection edit part did not set
its
> source/target to null if the source/target is not the edit part that is
> removing the connection.
>
> Going into begging mode: Please, oh please, can you make this change?
>
> "Randy Hudson" <none@us.ibm.com> wrote in message
> news:c6ruh1$8nv$1@eclipse.org...
> >
> > "Chris White" <cwhite@ic.net> wrote in message
> > news:c6rd84$ko7$1@eclipse.org...
> > > Randy,
> > >
> > > Here is what's happening in our application:
> > >
> > > We open our diagam/editor and set its contents based on the state of a
> > > number of resources. At this point Y is a target of C.
> > >
> > > The user then makes a modification to some resources (e.g. changes the
> > > target of C so that it points to Z and deletes Y). All of these
changes
> > can
> > > happen outside our editor. Our editor is notified of the change and
> > attempts
> > > the refresh. The refreshChildren method detects the new model object Z
> and
> > > gets its connections. It also knows that the old edit part has to be
> > > deleted. So at this point, both the model and the edit
parts/connections
> > are
> > > correct.
> > I would argue that the connections are not correct. Y should have
called
> > refreshTargetEditParts prior to Z's becoming the target of the
connection.
> > Even though Y is going to be deleted, you haven't deleted it yet, so it
is
> > still the target. A similar scenario is reparenting. The old editpart
in
> > the old parent must be deleted before the new editpart (for the same
model
> > object) is created in the new parent. Otherwise, connection will break
> > there too.
> >
> > > The only thing left is the cleanup of the deleted edit parts.
> > >
> > > But as you pointed out, the old edit part still exists and still knows
> > about
> > > its source and target connections. When it cleans up the old edit part
> it
> > > sets the target of the connection to null.
> > >
> > > It seems reasonable to me that the edit part should not set the
> > source/targt
> > > to null if the source/target are not the edit part.
> >
> > Possibly, or AbstractConnectionEditPart.setTarget(EditPart) could throw
an
> > exception if you are overwriting the existing target, which should have
> > removed itself.
> >
> > > We do reload the entire diagram. We listen for
> > > IResourceChangeEvent.POST_AUTO_BUILD event then reload the diagram.
> Since
> > > the model for the connection is often the same model object, this edit
> > part
> > > is not recreated.
> > >
> > > "Randy Hudson" <none@us.ibm.com> wrote in message
> > > news:c6r7qs$dq1$1@eclipse.org...
> > > > The problem is that you are refreshing (reconciling) the children,
but
> > you
> > > > are not reconciling the connections properly. At some point in your
> > > > execution and model notification, you have said that Z is the target
> of
> > C,
> > > > at the same time that Y is the target of Z. Connections are managed
> by
> > > > their nodes in GEF. So we currently require that a node release its
> > link
> > > to
> > > > a connection before another node assumes the same link (whether
source
> > or
> > > > target). Most models should work the same way. If you have modeled
> the
> > > > connections similarly (multiplicity of 1), then a connection can
only
> > have
> > > a
> > > > single target. When it's target is set to something new, it should
go
> > to
> > > > its old target an unhook itself. This is the way EMF bidirectional
> > > > reference work. And their notification, even if it is batched, will
> > come
> > > in
> > > > the correct order which reflects the changes made in the model.
> > > >
> > > > What are the specifics of your model and how it notifies to
editparts?
> > > > During this resource change, why don't you just reload the entire
> > diagram?
> > > >
> > > > "Chris White" <cwhite@ic.net> wrote in message
> > > > news:c6on47$l2c$1@eclipse.org...
> > > > > I thought I should give a better explanation of this problem.
> > > > >
> > > > > Say I have an diagram edit part that has two children with a
> > connection
> > > > > between them.
> > > > >
> > > > > [X]----C--->[Y]
> > > > >
> > > > > So now the model changes and X now connects to Z instead of Y (Y
is
> > > gone):
> > > > > The model behind the connection part is the same model object.
> > > > >
> > > > > [X]----C--->[Z]
> > > > >
> > > > > When the diagram is refreshed the new edit part for Z is created
and
> > the
> > > C
> > > > > connection edit part has its target set to Z. The refreshChildren
> > method
> > > > > then removes the unneeded edit part for Y. As part of the removal
it
> > > sets
> > > > > the target of C to null. So the connection ends up pointing to
> > nowhere.
> > > > >
> > > > > There is probably something I should be doing to avoid this
problem
> > but
> > > I
> > > > > don't know what it is. For now, I have had to override
removeNotify
> to
> > > get
> > > > > around the problem. Basically, the edit part only sets the source
or
> > > > target
> > > > > of the connection to null if it is the current source or target.
> > > > > public void removeNotify()
> > > > > {
> > > > > List conns;
> > > > > conns = getSourceConnections();
> > > > >
> > > > >
> > > > > while (conns.size() > 0) {
> > > > > ConnectionEditPart cep = (ConnectionEditPart)conns.get(0);
> > > > > if (cep.getSource() == this) {
> > > > > cep.setSource(null);
> > > > > } else {
> > > > > fireRemovingSourceConnection(cep,
> > > > > getSourceConnections().indexOf(cep));
> > > > > primRemoveSourceConnection(cep);
> > > > > }
> > > > > }
> > > > >
> > > > >
> > > > > conns = getTargetConnections();
> > > > > while (conns.size() > 0)
> > > > > {
> > > > > ConnectionEditPart cep = (ConnectionEditPart)conns.get(0);
> > > > > if (cep.getTarget() == this) {
> > > > > cep.setTarget(null);
> > > > > } else {
> > > > > fireRemovingTargetConnection(cep,
> > > > > getTargetConnections().indexOf(cep));
> > > > > primRemoveTargetConnection(cep);
> > > > > }
> > > > > }
> > > > >
> > > > >
> > > > > super.removeNotify();
> > > > >
> > > > > }
> > > > >
> > > > > }
> > > > >
> > > > >
> > > > > "Chris White" <cwhite@ic.net> wrote in message
> > > > > news:c6nci8$tno$1@eclipse.org...
> > > > > > I have a diagram where when a specific edit part refreshes,
> existing
> > > > > > connections are targeted to new child edit parts and some old
edit
> > > parts
> > > > > > that were targets of the same connections are deleted. When the
> > > children
> > > > > are
> > > > > > refreshed the connections are properly stiched to the new edit
> > parts.
> > > > > > However, the old edit parts are then deleted (in the
> refreshChildren
> > > > > method)
> > > > > > and the connection target is set to null.
> > > > > >
> > > > > > So the connections end up no target. Is there a way to avoid
this
> > > > > behavior?
> > > > > >
> > > > > >
> > > > >
> > > > >
> > > >
> > > >
> > >
> > >
> >
> >
>
>
|
|
|
| Re: Retargeted connections problem [message #133225 is a reply to message #132821] |
Thu, 20 May 2004 13:13 |
| Eclipse User |
|
|
|
Originally posted by: cwhite.ic.net
Randy,
Thank you very much for taking a shot at this.
I want to make sure that I understand the issues. I am still very green at
using GEF.
I am about to display the depth of my ignorance. When you say that I should
notify the old node that it is no longer the source of the connection, what
method are you suggesting I call on the old node/edit part to do this? I
have been relying on getModel(X)Connections to provide the correct set of
node connections but of course this is the source of the whole problem. I
think that once I understand how to do this I should be able to keep the
edit part containment and connection endpoints consistent.
The rest of this post describes some of the workarounds that I am using. I
am assuming that the changes you are making are similiar. Let me know if I
am missing the target.
I have made two changes in my edit part hieracrchy for various editors that
provide a termporary fix:
1) Overrrode removeSourceConnection and removeTargetConnection to check
ownership of the source/target. Sample below
protected void removeSourceConnection(ConnectionEditPart connection) {
fireRemovingSourceConnection(connection,
getSourceConnections().indexOf(connection));
if (connection.getSource() == this) // make sure we own the connection
source
{
connection.deactivate();
connection.setSource(null);
}
primRemoveSourceConnection(connection);
}
2) Overrrode removeNotify to perform the same check.
public void removeNotify()
{
List conns;
conns = getSourceConnections();
while (conns.size() > 0)
{
ConnectionEditPart cep = (ConnectionEditPart)conns.get(0);
if (cep.getSource() == this) // make sure we own the connection
source
{
cep.setSource(null);
}
else
{
fireRemovingSourceConnection(cep,
getSourceConnections().indexOf(cep));
primRemoveSourceConnection(cep);
}
}
These changes may be redundant. I made them in two separate diagram editors.
By making these changes, I no longer had connection that ended up with null
sources and targets. I obviosuly had to clone and tweak the entire super
class method implementation (not a good long term solution).
I think I and beginning to understand some of what you have been pointing
out. You are saying that at no time should an edit part or figure be
contained by more than one parent. Because of the nature of my use cases
this is difficult to acheive. It seems like you have the framework in place
to relax this restriction. The refreshChildren method seems to do a good job
of cleaning up an edits part's chidlren. The code just needs to allow
connection end points and the parent to be taken over by other edit parts.
I'm sure I'm under-estimating the effort required to allow this behavior.
I guessI have been thinking of the GEF edit part containment like a tree
viewer content provider. Even if my model does not support parented
behavior, I can use the content provider to make it appear like it does. I
can also rely on a complete refresh to correctly recalculate the tree
content.
..
"Randy Hudson" <none@us.ibm.com> wrote in message
news:c8e1lc$k4e$1@eclipse.org...
> We have made this change for you, but one more try and I will give up too.
> The notification is happening out of order, even in this new case you
> present. Some parent object holds all connections, which have a source
and
> target property. When you overwrite one of these properties, you should
> first notify the old node that it is no longer the source of the
connection,
> and it will call refresh..., then notify the new node.
>
> A similar scenario is adding a figure to a new parent. Even though you do
> not first remove the figure from its previous parent, there is no time at
> which you can find the figure in both old and new parent's children
Arrays.
> I believe the notification is also consistent.
>
> "Chris White" <cwhite@ic.net> wrote in message
> news:c8b9li$75e$1@eclipse.org...
> > One more try here and then I will give up.
> >
> > I have run into this problem again with another model.
> >
> > In this model, the links are managed by a parent model object. The child
> > model objects don't know about the links. We are using edit parts to
make
> > the connection by asking the parent model object for the appropriate
> > connections.
> >
> > When we retarget a connection, we simply change the model link to
reflect
> > the correct connection. Of course, we run to a problem when GEF removes
> the
> > connection edit part from the old source/target.
> >
> > Again, this would all work fine if the connection edit part did not set
> its
> > source/target to null if the source/target is not the edit part that is
> > removing the connection.
> >
> > Going into begging mode: Please, oh please, can you make this change?
> >
> > "Randy Hudson" <none@us.ibm.com> wrote in message
> > news:c6ruh1$8nv$1@eclipse.org...
> > >
> > > "Chris White" <cwhite@ic.net> wrote in message
> > > news:c6rd84$ko7$1@eclipse.org...
> > > > Randy,
> > > >
> > > > Here is what's happening in our application:
> > > >
> > > > We open our diagam/editor and set its contents based on the state of
a
> > > > number of resources. At this point Y is a target of C.
> > > >
> > > > The user then makes a modification to some resources (e.g. changes
the
> > > > target of C so that it points to Z and deletes Y). All of these
> changes
> > > can
> > > > happen outside our editor. Our editor is notified of the change and
> > > attempts
> > > > the refresh. The refreshChildren method detects the new model object
Z
> > and
> > > > gets its connections. It also knows that the old edit part has to be
> > > > deleted. So at this point, both the model and the edit
> parts/connections
> > > are
> > > > correct.
> > > I would argue that the connections are not correct. Y should have
> called
> > > refreshTargetEditParts prior to Z's becoming the target of the
> connection.
> > > Even though Y is going to be deleted, you haven't deleted it yet, so
it
> is
> > > still the target. A similar scenario is reparenting. The old
editpart
> in
> > > the old parent must be deleted before the new editpart (for the same
> model
> > > object) is created in the new parent. Otherwise, connection will
break
> > > there too.
> > >
> > > > The only thing left is the cleanup of the deleted edit parts.
> > > >
> > > > But as you pointed out, the old edit part still exists and still
knows
> > > about
> > > > its source and target connections. When it cleans up the old edit
part
> > it
> > > > sets the target of the connection to null.
> > > >
> > > > It seems reasonable to me that the edit part should not set the
> > > source/targt
> > > > to null if the source/target are not the edit part.
> > >
> > > Possibly, or AbstractConnectionEditPart.setTarget(EditPart) could
throw
> an
> > > exception if you are overwriting the existing target, which should
have
> > > removed itself.
> > >
> > > > We do reload the entire diagram. We listen for
> > > > IResourceChangeEvent.POST_AUTO_BUILD event then reload the diagram.
> > Since
> > > > the model for the connection is often the same model object, this
edit
> > > part
> > > > is not recreated.
> > > >
> > > > "Randy Hudson" <none@us.ibm.com> wrote in message
> > > > news:c6r7qs$dq1$1@eclipse.org...
> > > > > The problem is that you are refreshing (reconciling) the children,
> but
> > > you
> > > > > are not reconciling the connections properly. At some point in
your
> > > > > execution and model notification, you have said that Z is the
target
> > of
> > > C,
> > > > > at the same time that Y is the target of Z. Connections are
managed
> > by
> > > > > their nodes in GEF. So we currently require that a node release
its
> > > link
> > > > to
> > > > > a connection before another node assumes the same link (whether
> source
> > > or
> > > > > target). Most models should work the same way. If you have
modeled
> > the
> > > > > connections similarly (multiplicity of 1), then a connection can
> only
> > > have
> > > > a
> > > > > single target. When it's target is set to something new, it
should
> go
> > > to
> > > > > its old target an unhook itself. This is the way EMF
bidirectional
> > > > > reference work. And their notification, even if it is batched,
will
> > > come
> > > > in
> > > > > the correct order which reflects the changes made in the model.
> > > > >
> > > > > What are the specifics of your model and how it notifies to
> editparts?
> > > > > During this resource change, why don't you just reload the entire
> > > diagram?
> > > > >
> > > > > "Chris White" <cwhite@ic.net> wrote in message
> > > > > news:c6on47$l2c$1@eclipse.org...
> > > > > > I thought I should give a better explanation of this problem.
> > > > > >
> > > > > > Say I have an diagram edit part that has two children with a
> > > connection
> > > > > > between them.
> > > > > >
> > > > > > [X]----C--->[Y]
> > > > > >
> > > > > > So now the model changes and X now connects to Z instead of Y (Y
> is
> > > > gone):
> > > > > > The model behind the connection part is the same model object.
> > > > > >
> > > > > > [X]----C--->[Z]
> > > > > >
> > > > > > When the diagram is refreshed the new edit part for Z is created
> and
> > > the
> > > > C
> > > > > > connection edit part has its target set to Z. The
refreshChildren
> > > method
> > > > > > then removes the unneeded edit part for Y. As part of the
removal
> it
> > > > sets
> > > > > > the target of C to null. So the connection ends up pointing to
> > > nowhere.
> > > > > >
> > > > > > There is probably something I should be doing to avoid this
> problem
> > > but
> > > > I
> > > > > > don't know what it is. For now, I have had to override
> removeNotify
> > to
> > > > get
> > > > > > around the problem. Basically, the edit part only sets the
source
> or
> > > > > target
> > > > > > of the connection to null if it is the current source or target.
> > > > > > public void removeNotify()
> > > > > > {
> > > > > > List conns;
> > > > > > conns = getSourceConnections();
> > > > > >
> > > > > >
> > > > > > while (conns.size() > 0) {
> > > > > > ConnectionEditPart cep = (ConnectionEditPart)conns.get(0);
> > > > > > if (cep.getSource() == this) {
> > > > > > cep.setSource(null);
> > > > > > } else {
> > > > > > fireRemovingSourceConnection(cep,
> > > > > > getSourceConnections().indexOf(cep));
> > > > > > primRemoveSourceConnection(cep);
> > > > > > }
> > > > > > }
> > > > > >
> > > > > >
> > > > > > conns = getTargetConnections();
> > > > > > while (conns.size() > 0)
> > > > > > {
> > > > > > ConnectionEditPart cep = (ConnectionEditPart)conns.get(0);
> > > > > > if (cep.getTarget() == this) {
> > > > > > cep.setTarget(null);
> > > > > > } else {
> > > > > > fireRemovingTargetConnection(cep,
> > > > > > getTargetConnections().indexOf(cep));
> > > > > > primRemoveTargetConnection(cep);
> > > > > > }
> > > > > > }
> > > > > >
> > > > > >
> > > > > > super.removeNotify();
> > > > > >
> > > > > > }
> > > > > >
> > > > > > }
> > > > > >
> > > > > >
> > > > > > "Chris White" <cwhite@ic.net> wrote in message
> > > > > > news:c6nci8$tno$1@eclipse.org...
> > > > > > > I have a diagram where when a specific edit part refreshes,
> > existing
> > > > > > > connections are targeted to new child edit parts and some old
> edit
> > > > parts
> > > > > > > that were targets of the same connections are deleted. When
the
> > > > children
> > > > > > are
> > > > > > > refreshed the connections are properly stiched to the new edit
> > > parts.
> > > > > > > However, the old edit parts are then deleted (in the
> > refreshChildren
> > > > > > method)
> > > > > > > and the connection target is set to null.
> > > > > > >
> > > > > > > So the connections end up no target. Is there a way to avoid
> this
> > > > > > behavior?
> > > > > > >
> > > > > > >
> > > > > >
> > > > > >
> > > > >
> > > > >
> > > >
> > > >
> > >
> > >
> >
> >
>
>
|
|
|
| Re: Retargeted connections problem [message #135430 is a reply to message #133225] |
Tue, 01 June 2004 19:40 |
| Eclipse User |
|
|
|
Originally posted by: none.us.ibm.com
> I want to make sure that I understand the issues. I am still very green at
> using GEF.
>
> I am about to display the depth of my ignorance. When you say that I
should
> notify the old node that it is no longer the source of the connection,
what
> method are you suggesting I call on the old node/edit part to do this? I
> have been relying on getModel(X)Connections to provide the correct set of
> node connections but of course this is the source of the whole problem. I
> think that once I understand how to do this I should be able to keep the
> edit part containment and connection endpoints consistent.
notification probably requires your own "listener" api. If you have a
single "domain" notifier, then you can reroute notification to editparts,
again you may need them to expose additional methods so you can route the
type of change to the editpart.
But, once your editpart gets the method call, it can call
refreshSourceConnections(), or it call call directly
removeSourceConnection(), and addSourceConnection(). These other 2 methods
are more direct and faster. but the point was that the old source editpart
do this first, followed by the new source. The triggers are specific to
your application
|
|
|
Goto Forum:
Current Time: Sat Apr 27 00:04:03 GMT 2024
Powered by FUDForum. Page generated in 0.04247 seconds |
] 
Search
Help
Register
Login
Home
