Home » Eclipse Projects » GEF » Deleting compound connections
| Deleting compound connections [message #104462] |
Tue, 11 November 2003 11:55  |
Eclipse User |
|
|
|
Originally posted by: brian.fernandes.codito.com
In my editor I've implemented branched connections by connecting connections
to other connections.
When you select any of these connections, the connection editpart tracker
selects all the connections to which the clicked connection is connected.
Because this is sort of a hack to implement branched connections, I make
sure the tracker selects the primary connection first. (Secondary
connections are those which have one end attached to another connection). In
this way, the properties displayed in the property view are the properties
of the primary connection ~ because it was the first selected connection.
The properties of the secondary connections are worthless to me because it
is all supposed to be one single connection - which I consider to be the
primary connection.
This works fine... But I have a problem deleting the connection as a whole.
Because of the complexity of the implementation, all the secondary
connections MUST be deleted first and finally the primary connection must be
deleted. But if the primary connection is selected first, then exactly the
reverse happens.. the primary connection is deleted first.
So right now, I can either have the delete working or the selection /
properties but not both.
An idea I had was to select the primary connection both first and last and
let the first delete command (which would attempt to delete the primary
connection) have dummy execute and undo steps which do nothing. However in
the connection delete command, it is not possible for me to detect that this
is the first of a group of compound commands. Detecting this fact from the
model is a bit tricky because the connection will be identified as a primary
connection for both the first and last delete command... so I will have no
idea which one to skip.
The only place where something is possible is in
DeleteAction#createDeleteCommand(List objects)... should I hack it in here ?
subclass and create my own DeleteAction ?
Any cleaner suggestions ?
Thanks,
Brian.
--
If I bring you to it.
I will bring you through it. ~ God.
|
|
|
| Re: Deleting compound connections [message #104491 is a reply to message #104462] |
Tue, 11 November 2003 15:07  |
| Eclipse User |
|
|
|
Originally posted by: none.us.ibm.com
Sounds like a kluge. To hack around the delete problem, couldn't you just
have the secondary connections return NULL as their contribution to delete,
and have the primary connection do the entire delete in the correct order?
The secondary connections can do this only when the primary connection is
selected, and therefore being deleted. Otherwise you wouldn't be able to
delete just th 2ndary connection
"Brian Fernandes" <brian.fernandes@codito.com> wrote in message
news:boqhqv$71l$1@eclipse.org...
> In my editor I've implemented branched connections by connecting
connections
> to other connections.
>
> When you select any of these connections, the connection editpart tracker
> selects all the connections to which the clicked connection is connected.
>
> Because this is sort of a hack to implement branched connections, I make
> sure the tracker selects the primary connection first. (Secondary
> connections are those which have one end attached to another connection).
In
> this way, the properties displayed in the property view are the properties
> of the primary connection ~ because it was the first selected connection.
> The properties of the secondary connections are worthless to me because it
> is all supposed to be one single connection - which I consider to be the
> primary connection.
>
> This works fine... But I have a problem deleting the connection as a
whole.
> Because of the complexity of the implementation, all the secondary
> connections MUST be deleted first and finally the primary connection must
be
> deleted. But if the primary connection is selected first, then exactly
the
> reverse happens.. the primary connection is deleted first.
>
> So right now, I can either have the delete working or the selection /
> properties but not both.
>
> An idea I had was to select the primary connection both first and last and
> let the first delete command (which would attempt to delete the primary
> connection) have dummy execute and undo steps which do nothing. However in
> the connection delete command, it is not possible for me to detect that
this
> is the first of a group of compound commands. Detecting this fact from the
> model is a bit tricky because the connection will be identified as a
primary
> connection for both the first and last delete command... so I will have no
> idea which one to skip.
>
> The only place where something is possible is in
> DeleteAction#createDeleteCommand(List objects)... should I hack it in here
?
> subclass and create my own DeleteAction ?
>
> Any cleaner suggestions ?
>
> Thanks,
> Brian.
>
> --
> If I bring you to it.
> I will bring you through it. ~ God.
>
>
|
|
|
| Re: Deleting compound connections [message #104505 is a reply to message #104491] |
Tue, 11 November 2003 15:42 |
| Eclipse User |
|
|
|
Originally posted by: brian.fernandes.codito.com
"Randy Hudson" <none@us.ibm.com> wrote in message
news:boqtt1$lg2$1@eclipse.org...
> Sounds like a kluge. To hack around the delete problem, couldn't you just
> have the secondary connections return NULL as their contribution to
delete,
> and have the primary connection do the entire delete in the correct order?
> The secondary connections can do this only when the primary connection is
> selected, and therefore being deleted. Otherwise you
Since they are all supposed to be just one single connection, you can't
select any individual primary / secondary connection. So if you select the
connection, the tracker selects all the connections that are connected
directly or indirectly to it.
I forgot to mention, since I have selectable endpoints, you can delete the
secondary connections by deleting its endpoint.If you select the connection
however, the entire thing is supposed to be deleted...
Thanks for the time
Brian.
|
|
|
| Re: Deleting compound connections [message #104516 is a reply to message #104505] |
Tue, 11 November 2003 15:45 |
| Eclipse User |
|
|
|
Originally posted by: none.us.ibm.com
Well, if you are taking my suggestion, so that secondary connection don't
contribute to delete. And already they don't contribute to properties. Why
not *completely* prevent them from ever being selected? Register their
visuals with the primary connection's editpart. Make everything based off
what happens to the primary connection, and voila.
"Brian Fernandes" <brian.fernandes@codito.com> wrote in message
news:boqv3b$mru$1@eclipse.org...
>
> "Randy Hudson" <none@us.ibm.com> wrote in message
> news:boqtt1$lg2$1@eclipse.org...
> > Sounds like a kluge. To hack around the delete problem, couldn't you
just
> > have the secondary connections return NULL as their contribution to
> delete,
> > and have the primary connection do the entire delete in the correct
order?
> > The secondary connections can do this only when the primary connection
is
> > selected, and therefore being deleted. Otherwise you
>
> Since they are all supposed to be just one single connection, you can't
> select any individual primary / secondary connection. So if you select the
> connection, the tracker selects all the connections that are connected
> directly or indirectly to it.
>
> I forgot to mention, since I have selectable endpoints, you can delete the
> secondary connections by deleting its endpoint.If you select the
connection
> however, the entire thing is supposed to be deleted...
>
> Thanks for the time
> Brian.
>
>
|
|
|
| Re: Deleting compound connections [message #104525 is a reply to message #104516] |
Tue, 11 November 2003 16:13 |
| Eclipse User |
|
|
|
Originally posted by: brian.fernandes.codito.com
But I DO need to delete the secondary connections (this does not delete the
entire connection, but deletes only an appropriate branch of the
connection)... I also need to be able to reconnecect them, etc. And to top
it all, though the secondary connections don't have any properites, their
endpoints do have properties.
Is your suggestion still valid under these conditions ?
Another thing I can do is when I connect one connection to another, I should
copy all the properties from one of the connections to the other, then no
matter who is selected first, all the connections have the same properties.
In the light of all this, a simple additon to
DeleteAciton#createDeleteCommand will fix the issue quite simply, (at least
, that's how it looks before the attempt ;) - but then it isn't very clean.
I'll try out these idea and keep posting,
Thanks again,
Brian.
|
|
|
| Re: Deleting compound connections [message #104539 is a reply to message #104525] |
Tue, 11 November 2003 16:15 |
| Eclipse User |
|
|
|
Originally posted by: none.us.ibm.com
There are bugs open on the propertysheet requesting that is show the
properties of hte last selected item, not the first.
Also, as it becomes more enhanced (holding my breath), the UI will indicate
that multiple selection has occurred, and that the selected items have
different values.
"Brian Fernandes" <brian.fernandes@codito.com> wrote in message
news:bor0td$p9f$1@eclipse.org...
> But I DO need to delete the secondary connections (this does not delete
the
> entire connection, but deletes only an appropriate branch of the
> connection)... I also need to be able to reconnecect them, etc. And to
top
> it all, though the secondary connections don't have any properites, their
> endpoints do have properties.
>
> Is your suggestion still valid under these conditions ?
Only you would know. Can you show secondary connection properties on the
terminals?
>
> Another thing I can do is when I connect one connection to another, I
should
> copy all the properties from one of the connections to the other, then no
> matter who is selected first, all the connections have the same
properties.
>
> In the light of all this, a simple additon to
> DeleteAciton#createDeleteCommand will fix the issue quite simply, (at
least
> , that's how it looks before the attempt ;) - but then it isn't very
clean.
>
> I'll try out these idea and keep posting,
>
> Thanks again,
>
> Brian.
>
>
>
|
|
|
Goto Forum:
Current Time: Fri Jan 03 03:13:31 GMT 2025
Powered by FUDForum. Page generated in 0.03394 seconds |
] 
Search
Help
Register
Login
Home
