Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » GMF (Graphical Modeling Framework) » Changing between different Figures
Changing between different Figures [message #211809] Sat, 22 November 2008 16:02 Go to next message
Eclipse UserFriend
Originally posted by: cayla_sha.gmx.net

Hello!

In my project I have (amongst others) 3 Classes: "Location", "Station"
and "Depot". As you can see, these are all synonyms for some kind of
place, but they look very different and have (a bit) different
attributes. There is also some kind of connection to connect the places.

Nomally there are 3 Tools, one for each of them, and I can draw all 3 of
them.
What I want to do now is this: I want do change between the different
places. I imagine it like this: When I draw for example a Depot, there
is a DropDown on its Properties-View where I have "depot", "location"
and "station" to choose. And when I choose for example "station" then
the appearence will change and from now on this object is a Station.
The changing is important, because when I just delete the Depot and
create a Station, then all connections to other places are lost.

For this type-dropDown in the Properties-View I created already an
Enumeration-Class. The dropDown is working. I even managed it, that the
right type is set, when I create a new place.

So far I tried 2 different approaches:
1. I have 3 classes, one class for each place, and when the type is
changed I tried to delete the old Object and create a new one. My
Problems on this approach:
- I couldn`t find an appropriate place to store the code. The only place
where I found that the call is passing is in the method "setType" in the
class itself. But there I'm IN the class I want to delete. I don`t
think, this will work.
- And I didn`t find the methods which I need to call for deletion and
creation.

2. I have just 1 class, called "Place". But I have 3 Nodes in the
gmfgraph, 3 Tools in the Tooling Definition and of course 3 Mappings. (I
tried to copy the idea from this Tutorial:
http://wiki.eclipse.org/GMF_Tutorial_Part_2#Feature_Initiali zers) This
approach led to a totally broken Project where I couldn`t draw any nodes...

Which approach do you favor? Any ideas for one of the approaches to
work? Any idea for a totally other approach (perhaps I just have a plank
of wood in front of my head/I can`t think straight at the moment and the
solution is very easy)?

Best whishes and thanks in advance
Julia
Re: Changing between different Figures [message #211885 is a reply to message #211809] Mon, 24 November 2008 12:06 Go to previous messageGo to next message
Alexander Shatalin is currently offline Alexander ShatalinFriend
Messages: 2928
Registered: July 2009
Senior Member
Hello Cayla,

> 2. I have just 1 class, called "Place". But I have 3 Nodes in the
> gmfgraph, 3 Tools in the Tooling Definition and of course 3 Mappings.
This is right. You have to add 3 constraints for each of NodeMappings to
make "Place" representable by only one NodeMappings at a time.
Then, i suppose, you'll have some problems with diagram update - you should
change corresponding property of "Place" in properties view and reopen the
diagram editor or press F5 when diagram surface is selected to see diagram
node changes. To solve this problem you can call diagram update using corresponding
property change event from EMF.

-----------------
Alex Shatalin
Re: Changing between different Figures [message #214453 is a reply to message #211885] Sat, 03 January 2009 13:06 Go to previous messageGo to next message
Eclipse UserFriend
Originally posted by: cayla_sha.gmx.net

Hello Alex!

Now I have the problem with the diagram update like you anticipated :(
(In the meantime a fixed all the other problems of my diagram and the
last thing what is left over is the update)

What do you mean with "To solve this problem you can call diagram update
using corresponding property change event from EMF." ?
What is a "property change event from EMF"? Can you tell me the call? Or
at least the class?

I read this article: "Extending your DSM by leveraging the GMF Runtime"
(Anthony Hunter, Mohammed Mostafa, eclipsecon
2007)( http://eclipsezilla.eclipsecon.org/php/attachment.php?bugid= 3624)
On slide 34 they describe a simliar problem. I tried their solution, but
it doesn`t work. At the end of the slide they use "refreshLabel()".
Instead tried refresh() and refreshChildren() (because I don`t want to
refresh the Label but the whole figure) but both didn`t work.
Is this the right approach for my problem?

Best wishes and thanks in advance!
Julia
Re: Changing between different Figures [message #214575 is a reply to message #214453] Mon, 05 January 2009 14:41 Go to previous messageGo to next message
Alexander Shatalin is currently offline Alexander ShatalinFriend
Messages: 2928
Registered: July 2009
Senior Member
Hello Cayla,

If pressing F5 halps in your situation then you have to call this action
(see EcoreDiagramUpdateCommand) on corresponding EMF notification (place
a breakpoint into Location/Station/DepotEditPart.handleNotificationEvent()
and make a modification in Location/Station/Depot to see that this method
is called for each modification)

-----------------
Alex Shatalin
Re: Changing between different Figures [message #214705 is a reply to message #214575] Wed, 07 January 2009 14:56 Go to previous messageGo to next message
Eclipse UserFriend
Originally posted by: cayla_sha.gmx.net

Hello Alex!

I have a problem with the F5-command. It doesn`t work, when I call
DsceditorDiagramUpdateCommand.execute(). It is because the
LocationEditPart is selected at the time, when I want it to be
refreshed, and not the ShapesDiagramEditPart. Pressing F5 helps only,
when the whole diagram is selected, and not when only one node is selected.

I decided to copy the code from the execute-method. I get the
ShapesDiagramEditPart with getParent() and then I do everything like it
is done in the execute-method.
But with this I get an error:

java.lang.IllegalArgumentException: Argument 'nodes' contains objects
which have a different parent containment
at
org.eclipse.gmf.runtime.diagram.ui.services.layout.LayoutSer vice.checkValidLayoutNodes(LayoutService.java:120)
at
org.eclipse.gmf.runtime.diagram.ui.services.layout.LayoutSer vice.layoutLayoutNodes(LayoutService.java:294)
at
org.eclipse.gmf.runtime.diagram.ui.editpolicies.ContainerEdi tPolicy.layoutNodes(ContainerEditPolicy.java:374)
at
org.eclipse.gmf.runtime.diagram.ui.editpolicies.ContainerEdi tPolicy.getArrangeCommand(ContainerEditPolicy.java:329)
at
org.eclipse.gmf.runtime.diagram.ui.editpolicies.ContainerEdi tPolicy.getCommand(ContainerEditPolicy.java:509)
at
org.eclipse.gef.editparts.AbstractEditPart.getCommand(Abstra ctEditPart.java:473)
at
org.eclipse.gmf.runtime.diagram.ui.editparts.GraphicalEditPa rt.access$1(GraphicalEditPart.java:1)
at
org.eclipse.gmf.runtime.diagram.ui.editparts.GraphicalEditPa rt$1.run(GraphicalEditPart.java:466)
at
org.eclipse.emf.transaction.impl.TransactionalEditingDomainI mpl.runExclusive(TransactionalEditingDomainImpl.java:289)
at
org.eclipse.gmf.runtime.diagram.ui.editparts.GraphicalEditPa rt.getCommand(GraphicalEditPart.java:461)
.....

Interestingly the exception is not thrown from my code but it triggers
it in some way. When I comment my code then there`s no exception.
I find it strange that my code could trigger this exception, because I
only "get" and "refresh" things. I don`t "write" anything, so how can I
change the parent containment of nodes?

Any help is appreciated.
Best wishes and thanks in advance!
Julia
Re: Changing between different Figures [message #214804 is a reply to message #214705] Thu, 08 January 2009 13:03 Go to previous messageGo to next message
Alexander Shatalin is currently offline Alexander ShatalinFriend
Messages: 2928
Registered: July 2009
Senior Member
Hello Cayla,

Can you place a breakpoint into
> org.eclipse.gmf.runtime.diagram.ui.services.layout.LayoutSer vice.check
> ValidLayoutNodes(LayoutService.java:120)
to se wich particular not is violating constraints and why.

-----------------
Alex Shatalin
Re: Changing between different Figures [message #214860 is a reply to message #214804] Thu, 08 January 2009 20:43 Go to previous messageGo to next message
Eclipse UserFriend
Originally posted by: cayla_sha.gmx.net

Hello Alex!

I put a breakpoint there and that is what I discovered:
It fails the last test, because the eContainer of one of the nodes is
null. The whole node looked very "nulled", nearly every variable was
null. The "nulled"-node is exactly the node I refresh with my
F5-command. I could it only discover by its type. But the type was
false: It was 1001.
First, it is ok, that the type is 1001 (a LocationEditPart), but then I
change the data and thereupon my F5-command is called to change the
appearance. And with the change of the appearance the EditPart (and the
type) should change,too. But it`s still 1001.

It seems to me as if the program has problems with the change of the
EditPart. Perhaps it deletes the old node, but continues using it. Or it
fails creating a new node.

But the simple press on F5 works perfect.
But I`m doing the exact same thing as it is done in the F5-command,
except for one thing: The F5-command gets the ShapesDiagramEditPart out
of the currentSelection and I get it over the parent of the currently
selected EditPart. I already debugged my code and the code of the
F5-command and both use the same methods on the same objects.
*puzzled*

Thanks in advance for any help!
Julia
Re: Changing between different Figures [message #214913 is a reply to message #214860] Fri, 09 January 2009 13:26 Go to previous messageGo to next message
Alexander Shatalin is currently offline Alexander ShatalinFriend
Messages: 2928
Registered: July 2009
Senior Member
Hello Cayla,

I can imagine the problem is in inconsistent model contents during update
execution from .handleNotificationEvent() method. You can try understanding
what’s happening after this method execution (some other notation model updates
performed)?
Try calling diagram update (F5) with a delay (in another thread) – to let
all the other notifications gone. But this sounds really strange for me –
I remember other postings in this newsgroup telling everything is ok with
same situations.

-----------------
Alex Shatalin
Re: Changing between different Figures [message #215202 is a reply to message #214913] Wed, 14 January 2009 14:27 Go to previous messageGo to next message
Eclipse UserFriend
Originally posted by: cayla_sha.gmx.net

This is a multi-part message in MIME format.
--------------080305070607040802090005
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

Hello Alex,

now I do my F5 command in a separate thread, but this doesn`t change
anything. It just lasts longer because of the sleep in the thread... The
behaviour is still the same: I click on the Location-node, I click "New
Vehicle" on the property-tab, in the background a new vehicle is created
and added to the Location, the LocationEditPart receives the
notification, I call my F5 command, the appearance of the node doesn`t
change. And then I click somewhere else on the diagram and the Exception
is thrown.

Perhaps something is wrong with my thread...? I`m not so used to threads...
I add my whole LocationEditPart to my Mail, because I`m very desperate
right now. I really need to get this working... The thread is in the
method "myF5command(), it is the second method from the bottom. All
methods where I`ve done something are marked with "@generated NOT".
Perhaps you can see the fault...?

"I remember other postings in this newsgroup telling everything is ok
with same situations."
So, how do others do this?
You can`t call XXX.diagram.part.DsceditorDiagramUpdateCommand.execute()
out of a EditPart because this method needs the selection of the
Diagram. F5 never works when a Node is selected.
So how do they call this F5-command out of a EditPart?

Help!
Julia

--------------080305070607040802090005
Content-Type: text/plain;
name="LocationEditPart.java"
Content-Transfer-Encoding: base64
Content-Disposition: inline;
filename="LocationEditPart.java"

cGFja2FnZSBkZS5wdnMuZHNjLmVkaXRvci5kaWFncmFtLmVkaXQucGFydHM7 DQoNCmltcG9y
dCBqYXZhLnV0aWwuSXRlcmF0b3I7DQppbXBvcnQgamF2YS51dGlsLkxpc3Q7 DQoNCmltcG9y
dCBvcmcuZWNsaXBzZS5kcmF3MmQuQ29sb3JDb25zdGFudHM7DQppbXBvcnQg b3JnLmVjbGlw
c2UuZHJhdzJkLklGaWd1cmU7DQppbXBvcnQgb3JnLmVjbGlwc2UuZHJhdzJk LlJvdW5kZWRS
ZWN0YW5nbGU7DQppbXBvcnQgb3JnLmVjbGlwc2UuZHJhdzJkLlN0YWNrTGF5 b3V0Ow0KaW1w
b3J0IG9yZy5lY2xpcHNlLmRyYXcyZC5nZW9tZXRyeS5EaW1lbnNpb247DQpp bXBvcnQgb3Jn
LmVjbGlwc2UuZHJhdzJkLmdlb21ldHJ5LlBvaW50Ow0KaW1wb3J0IG9yZy5l Y2xpcHNlLmRy
YXcyZC5nZW9tZXRyeS5SZWN0YW5nbGU7DQppbXBvcnQgb3JnLmVjbGlwc2Uu ZW1mLmNvbW1v
bi5ub3RpZnkuTm90aWZpY2F0aW9uOw0KaW1wb3J0IG9yZy5lY2xpcHNlLmVt Zi5lY29yZS5F
T2JqZWN0Ow0KaW1wb3J0IG9yZy5lY2xpcHNlLmVtZi5lY29yZS5pbXBsLkVB dHRyaWJ1dGVJ
bXBsOw0KaW1wb3J0IG9yZy5lY2xpcHNlLmdlZi5FZGl0UGFydDsNCmltcG9y dCBvcmcuZWNs
aXBzZS5nZWYuRWRpdFBvbGljeTsNCmltcG9ydCBvcmcuZWNsaXBzZS5nZWYu R3JhcGhpY2Fs
RWRpdFBhcnQ7DQppbXBvcnQgb3JnLmVjbGlwc2UuZ2VmLlJlcXVlc3Q7DQpp bXBvcnQgb3Jn
LmVjbGlwc2UuZ2VmLmNvbW1hbmRzLkNvbW1hbmQ7DQppbXBvcnQgb3JnLmVj bGlwc2UuZ2Vm
LmVkaXRwb2xpY2llcy5MYXlvdXRFZGl0UG9saWN5Ow0KaW1wb3J0IG9yZy5l Y2xpcHNlLmdl
Zi5lZGl0cG9saWNpZXMuTm9uUmVzaXphYmxlRWRpdFBvbGljeTsNCmltcG9y dCBvcmcuZWNs
aXBzZS5nZWYucmVxdWVzdHMuQ3JlYXRlUmVxdWVzdDsNCmltcG9ydCBvcmcu ZWNsaXBzZS5n
bWYucnVudGltZS5kaWFncmFtLnVpLmVkaXRwYXJ0cy5TaGFwZU5vZGVFZGl0 UGFydDsNCmlt
cG9ydCBvcmcuZWNsaXBzZS5nbWYucnVudGltZS5kaWFncmFtLnVpLmVkaXRw b2xpY2llcy5D
YW5vbmljYWxFZGl0UG9saWN5Ow0KaW1wb3J0IG9yZy5lY2xpcHNlLmdtZi5y dW50aW1lLmRp
YWdyYW0udWkuZWRpdHBvbGljaWVzLkVkaXRQb2xpY3lSb2xlczsNCmltcG9y dCBvcmcuZWNs
aXBzZS5nbWYucnVudGltZS5nZWYudWkuZmlndXJlcy5EZWZhdWx0U2l6ZU5v ZGVGaWd1cmU7
DQppbXBvcnQgb3JnLmVjbGlwc2UuZ21mLnJ1bnRpbWUuZ2VmLnVpLmZpZ3Vy ZXMuTm9kZUZp
Z3VyZTsNCmltcG9ydCBvcmcuZWNsaXBzZS5nbWYucnVudGltZS5ub3RhdGlv bi5EaWFncmFt
Ow0KaW1wb3J0IG9yZy5lY2xpcHNlLmdtZi5ydW50aW1lLm5vdGF0aW9uLk5v dGF0aW9uUGFj
a2FnZTsNCmltcG9ydCBvcmcuZWNsaXBzZS5nbWYucnVudGltZS5ub3RhdGlv bi5WaWV3Ow0K
aW1wb3J0IG9yZy5lY2xpcHNlLmdtZi5ydW50aW1lLm5vdGF0aW9uLmltcGwu Qm91bmRzSW1w
bDsNCmltcG9ydCBvcmcuZWNsaXBzZS5nbWYucnVudGltZS5ub3RhdGlvbi5p bXBsLk5vZGVJ
bXBsOw0KDQppbXBvcnQgZGUucHZzLmRzYy5lZGl0b3IuRWRpdG9yUGFja2Fn ZTsNCmltcG9y
dCBkZS5wdnMuZHNjLmVkaXRvci5Mb2NhdGlvbjsNCmltcG9ydCBkZS5wdnMu ZHNjLmVkaXRv
ci5kaWFncmFtLmVkaXQucG9saWNpZXMuTG9jYXRpb25JdGVtU2VtYW50aWNF ZGl0UG9saWN5
Ow0KaW1wb3J0IGRlLnB2cy5kc2MuZWRpdG9yLmltcGwuTG9jYXRpb25JbXBs Ow0KDQovKioN
CiAqIEBnZW5lcmF0ZWQNCiAqLw0KcHVibGljIGNsYXNzIExvY2F0aW9uRWRp dFBhcnQgZXh0
ZW5kcyBTaGFwZU5vZGVFZGl0UGFydCB7DQoNCgkvKioNCgkgKiBAZ2VuZXJh dGVkDQoJICov
DQoJcHVibGljIHN0YXRpYyBmaW5hbCBpbnQgVklTVUFMX0lEID0gMTAwMTsN Cg0KCS8qKg0K
CSAqIEBnZW5lcmF0ZWQNCgkgKi8NCglwcm90ZWN0ZWQgSUZpZ3VyZSBjb250 ZW50UGFuZTsN
Cg0KCS8qKg0KCSAqIEBnZW5lcmF0ZWQNCgkgKi8NCglwcm90ZWN0ZWQgSUZp Z3VyZSBwcmlt
YXJ5U2hhcGU7DQoNCgkvKioNCgkgKiBAZ2VuZXJhdGVkDQoJICovDQoJcHVi bGljIExvY2F0
aW9uRWRpdFBhcnQoVmlldyB2aWV3KSB7DQoJCXN1cGVyKHZpZXcpOw0KCX0N Cg0KCS8qKg0K
CSAqIEBnZW5lcmF0ZWQNCgkgKi8NCglwcm90ZWN0ZWQgdm9pZCBjcmVhdGVE ZWZhdWx0RWRp
dFBvbGljaWVzKCkgew0KCQlzdXBlci5jcmVhdGVEZWZhdWx0RWRpdFBvbGlj aWVzKCk7DQoJ
CWluc3RhbGxFZGl0UG9saWN5KEVkaXRQb2xpY3lSb2xlcy5TRU1BTlRJQ19S T0xFLA0KCQkJ
CW5ldyBMb2NhdGlvbkl0ZW1TZW1hbnRpY0VkaXRQb2xpY3koKSk7DQoJCWlu c3RhbGxFZGl0
UG9saWN5KEVkaXRQb2xpY3kuTEFZT1VUX1JPTEUsIGNyZWF0ZUxheW91dEVk aXRQb2xpY3ko
KSk7DQoJCS8vIFhYWCBuZWVkIGFuIFNDUiB0byBydW50aW1lIHRvIGhhdmUg YW5vdGhlciBh
YnN0cmFjdCBzdXBlcmNsYXNzIHRoYXQgd291bGQgbGV0IGNoaWxkcmVuIGFk ZCByZWFzb25h
YmxlIGVkaXRwb2xpY2llcw0KCQkvLyByZW1vdmVFZGl0UG9saWN5KG9yZy5l Y2xpcHNlLmdt
Zi5ydW50aW1lLmRpYWdyYW0udWkuZWRpdHBvbGljaWVzLkVkaXRQb2xpY3lS b2xlcy5DT05O
RUNUSU9OX0hBTkRMRVNfUk9MRSk7DQoJfQ0KDQoJLyoqDQoJICogQGdlbmVy YXRlZA0KCSAq
Lw0KCXByb3RlY3RlZCBMYXlvdXRFZGl0UG9saWN5IGNyZWF0ZUxheW91dEVk aXRQb2xpY3ko
KSB7DQoJCUxheW91dEVkaXRQb2xpY3kgbGVwID0gbmV3IExheW91dEVkaXRQ b2xpY3koKSB7
DQoNCgkJCXByb3RlY3RlZCBFZGl0UG9saWN5IGNyZWF0ZUNoaWxkRWRpdFBv bGljeShFZGl0
UGFydCBjaGlsZCkgew0KCQkJCUVkaXRQb2xpY3kgcmVzdWx0ID0gY2hpbGQN CgkJCQkJCS5n
ZXRFZGl0UG9saWN5KEVkaXRQb2xpY3kuUFJJTUFSWV9EUkFHX1JPTEUpOw0K CQkJCWlmIChy
ZXN1bHQgPT0gbnVsbCkgew0KCQkJCQlyZXN1bHQgPSBuZXcgTm9uUmVzaXph YmxlRWRpdFBv
bGljeSgpOw0KCQkJCX0NCgkJCQlyZXR1cm4gcmVzdWx0Ow0KCQkJfQ0KDQoJ CQlwcm90ZWN0
ZWQgQ29tbWFuZCBnZXRNb3ZlQ2hpbGRyZW5Db21tYW5kKFJlcXVlc3QgcmVx dWVzdCkgew0K
CQkJCXJldHVybiBudWxsOw0KCQkJfQ0KDQoJCQlwcm90ZWN0ZWQgQ29tbWFu ZCBnZXRDcmVh
dGVDb21tYW5kKENyZWF0ZVJlcXVlc3QgcmVxdWVzdCkgew0KCQkJCXJldHVy biBudWxsOw0K
CQkJfQ0KCQl9Ow0KCQlyZXR1cm4gbGVwOw0KCX0NCg0KCS8qKg0KCSAqIEBn ZW5lcmF0ZWQN
CgkgKi8NCglwcm90ZWN0ZWQgSUZpZ3VyZSBjcmVhdGVOb2RlU2hhcGUoKSB7 DQoJCUxvY2F0
aW9uRmlndXJlIGZpZ3VyZSA9IG5ldyBMb2NhdGlvbkZpZ3VyZSgpOw0KCQly ZXR1cm4gcHJp
bWFyeVNoYXBlID0gZmlndXJlOw0KCX0NCg0KCS8qKg0KCSAqIEBnZW5lcmF0 ZWQNCgkgKi8N
CglwdWJsaWMgTG9jYXRpb25GaWd1cmUgZ2V0UHJpbWFyeVNoYXBlKCkgew0K CQlyZXR1cm4g
KExvY2F0aW9uRmlndXJlKSBwcmltYXJ5U2hhcGU7DQoJfQ0KDQoJLyoqDQoJ ICogQGdlbmVy
YXRlZA0KCSAqLw0KCXByb3RlY3RlZCBOb2RlRmlndXJlIGNyZWF0ZU5vZGVQ bGF0ZSgpIHsN
CgkJRGVmYXVsdFNpemVOb2RlRmlndXJlIHJlc3VsdCA9IG5ldyBEZWZhdWx0 U2l6ZU5vZGVG
aWd1cmUoZ2V0TWFwTW9kZSgpDQoJCQkJLkRQdG9MUCgyMCksIGdldE1hcE1v ZGUoKS5EUHRv
TFAoMjApKTsNCgkJcmV0dXJuIHJlc3VsdDsNCgl9DQoNCgkvKioNCgkgKiBD cmVhdGVzIGZp
Z3VyZSBmb3IgdGhpcyBlZGl0IHBhcnQuDQoJICogDQoJICogQm9keSBvZiB0 aGlzIG1ldGhv
ZCBkb2VzIG5vdCBkZXBlbmQgb24gc2V0dGluZ3MgaW4gZ2VuZXJhdGlvbiBt b2RlbA0KCSAq
IHNvIHlvdSBtYXkgc2FmZWx5IHJlbW92ZSA8aT5nZW5lcmF0ZWQ8L2k+IHRh ZyBhbmQgbW9k
aWZ5IGl0Lg0KCSAqIA0KCSAqIEBnZW5lcmF0ZWQNCgkgKi8NCglwcm90ZWN0 ZWQgTm9kZUZp
Z3VyZSBjcmVhdGVOb2RlRmlndXJlKCkgew0KCQlOb2RlRmlndXJlIGZpZ3Vy ZSA9IGNyZWF0
ZU5vZGVQbGF0ZSgpOw0KCQlmaWd1cmUuc2V0TGF5b3V0TWFuYWdlcihuZXcg U3RhY2tMYXlv
dXQoKSk7DQoJCUlGaWd1cmUgc2hhcGUgPSBjcmVhdGVOb2RlU2hhcGUoKTsN CgkJZmlndXJl
LmFkZChzaGFwZSk7DQoJCWNvbnRlbnRQYW5lID0gc2V0dXBDb250ZW50UGFu ZShzaGFwZSk7
DQoJCXJldHVybiBmaWd1cmU7DQoJfQ0KDQoJLyoqDQoJICogRGVmYXVsdCBp bXBsZW1lbnRh
dGlvbiB0cmVhdHMgcGFzc2VkIGZpZ3VyZSBhcyBjb250ZW50IHBhbmUuDQoJ ICogUmVzcGVj
dHMgbGF5b3V0IG9uZSBtYXkgaGF2ZSBzZXQgZm9yIGdlbmVyYXRlZCBmaWd1 cmUuDQoJICog
QHBhcmFtIG5vZGVTaGFwZSBpbnN0YW5jZSBvZiBnZW5lcmF0ZWQgZmlndXJl IGNsYXNzDQoJ
ICogQGdlbmVyYXRlZA0KCSAqLw0KCXByb3RlY3RlZCBJRmlndXJlIHNldHVw Q29udGVudFBh
bmUoSUZpZ3VyZSBub2RlU2hhcGUpIHsNCgkJcmV0dXJuIG5vZGVTaGFwZTsg Ly8gdXNlIG5v
ZGVTaGFwZSBpdHNlbGYgYXMgY29udGVudFBhbmUNCgl9DQoNCgkvKioNCgkg KiBAZ2VuZXJh
dGVkDQoJICovDQoJcHVibGljIElGaWd1cmUgZ2V0Q29udGVudFBhbmUoKSB7 DQoJCWlmIChj
b250ZW50UGFuZSAhPSBudWxsKSB7DQoJCQlyZXR1cm4gY29udGVudFBhbmU7 DQoJCX0NCgkJ
cmV0dXJuIHN1cGVyLmdldENvbnRlbnRQYW5lKCk7DQoJfQ0KDQoJLyoqDQoJ ICogQGdlbmVy
YXRlZCBOT1QNCgkgKi8NCglAT3ZlcnJpZGUNCglwcm90ZWN0ZWQgdm9pZCBh ZGROb3RhdGlv
bmFsTGlzdGVuZXJzKCl7DQoJCS8vIG93biBsaXN0ZW5lciB0byBnZXQgaW5m b3JtZWQsIHdo
ZW4gDQoJCS8vIHZlaGljbGVzLCBzdGF0aW9ucyBvciBkZXBvdHMgYXJlIGFk ZGVkIG9yIHJl
bW92ZWQNCgkJDQoJCURpYWdyYW0gZGlhZ3JhbSA9IHRoaXMuZ2V0RGlhZ3Jh bVZpZXcoKTsN
CgkJaWYgKGRpYWdyYW0gIT0gbnVsbCkNCgkJew0KCQkJICAgYWRkTGlzdGVu ZXJGaWx0ZXIo
IkxvY2F0aW9uU3R5bGVfVmVoaWNsZXMiLCB0aGlzLCBkaWFncmFtLCBFZGl0 b3JQYWNrYWdl
LkxpdGVyYWxzLkxPQ0FUSU9OX19OVU1CRVJfT0ZfVkVISUNMRVMpOw0KCQkJ ICAgYWRkTGlz
dGVuZXJGaWx0ZXIoIkxvY2F0aW9uU3R5bGVfU3RhdGlvbnMiLCB0aGlzLCBk aWFncmFtLCBF
ZGl0b3JQYWNrYWdlLkxpdGVyYWxzLkxPQ0FUSU9OX19OVU1CRVJfT0ZfU1RB VElPTlMpOw0K
CQkJICAgYWRkTGlzdGVuZXJGaWx0ZXIoIkxvY2F0aW9uU3R5bGVfRGVwb3Rz IiwgdGhpcywg
ZGlhZ3JhbSwgRWRpdG9yUGFja2FnZS5MaXRlcmFscy5MT0NBVElPTl9fTlVN QkVSX09GX0RF
UE9UUyk7DQoJCX0NCgkJDQoJCXN1cGVyLmFkZE5vdGF0aW9uYWxMaXN0ZW5l cnMoKTsNCgl9
DQoJDQoJLyoqDQoJICogQGdlbmVyYXRlZCBOT1QNCgkgKi8NCglAT3ZlcnJp ZGUNCglwcm90
ZWN0ZWQgdm9pZCByZW1vdmVOb3RhdGlvbmFsTGlzdGVuZXJzKCkgew0KCQkv LyByZW1vdmUg
TGlzdGVuZXJzIGJlZm9yZSB0aGUgbm9kZSBpcyBkaXNwb3NlZA0KCQkNCgkJ cmVtb3ZlTGlz
dGVuZXJGaWx0ZXIoIkxvY2F0aW9uU3R5bGVfVmVoaWNsZXMiKTsNCgkJcmVt b3ZlTGlzdGVu
ZXJGaWx0ZXIoIkxvY2F0aW9uU3R5bGVfU3RhdGlvbnMiKTsNCgkJcmVtb3Zl TGlzdGVuZXJG
aWx0ZXIoIkxvY2F0aW9uU3R5bGVfRGVwb3RzIik7DQoJCQ0KCQlzdXBlci5y ZW1vdmVOb3Rh
dGlvbmFsTGlzdGVuZXJzKCk7DQoJfQ0KCQ0KCS8qKg0KCSAqIEBnZW5lcmF0 ZWQgTk9UDQoJ
ICovDQoJQE92ZXJyaWRlDQoJcHJvdGVjdGVkIHZvaWQgaGFuZGxlTm90aWZp Y2F0aW9uRXZl
bnQoTm90aWZpY2F0aW9uIG5vdGlmaWNhdGlvbikgDQoJew0KCQkvLyBmb3Ig dGhlIGNhc2Us
IHdoZW4gYSBuZXcgdmVoaWNsZS9zdGF0aW9uL2RlcG90IHdhcyBjcmVhdGVk IGFuZCBhZGRl
ZCB0byBMb2NhdGlvbg0KCQlPYmplY3QgZmVhdHVyZSA9IG5vdGlmaWNhdGlv bi5nZXRGZWF0
dXJlKCk7DQoJCWlmKEVkaXRvclBhY2thZ2UuTGl0ZXJhbHMuTE9DQVRJT05f X05VTUJFUl9P
Rl9WRUhJQ0xFUy5lcXVhbHMoZmVhdHVyZSkpDQoJCXsNCgkJCW15RjVDb21t YW5kKCk7DQoJ
CX0NCgkJZWxzZSBpZihFZGl0b3JQYWNrYWdlLkxpdGVyYWxzLkxPQ0FUSU9O X19OVU1CRVJf
T0ZfU1RBVElPTlMuZXF1YWxzKGZlYXR1cmUpKQ0KCQl7DQoJCQlteUY1Q29t bWFuZCgpOw0K
CQl9DQoJCWVsc2UgaWYoRWRpdG9yUGFja2FnZS5MaXRlcmFscy5MT0NBVElP Tl9fTlVNQkVS
X09GX0RFUE9UUy5lcXVhbHMoZmVhdHVyZSkpDQoJCXsNCgkJCW15RjVDb21t YW5kKCk7DQoJ
CX0NCgkJDQoJCWlmIChub3RpZmljYXRpb24uZ2V0RXZlbnRUeXBlKCkgPT0g Tm90aWZpY2F0
aW9uLlNFVCkgDQoJCXsNCgkJCS8vIGZvciB0aGUgY2FzZSwgd2hlbiB0aGUg TG9jYXRpb24t
U2hhcGUgaXMgbW92ZWQNCgkJCWlmIChub3RpZmljYXRpb24uZ2V0Tm90aWZp ZXIoKSBpbnN0
YW5jZW9mIEJvdW5kc0ltcGwpIA0KCQkJew0KCQkJCUJvdW5kc0ltcGwgbm90 aWZpZXIgPSAo
Qm91bmRzSW1wbCkgbm90aWZpY2F0aW9uLmdldE5vdGlmaWVyKCk7DQoJCQkJ Tm9kZUltcGwg
bm9kZSA9IChOb2RlSW1wbCkgdGhpcy5nZXRNb2RlbCgpOw0KCQkJCUxvY2F0 aW9uSW1wbCBt
b2RlbCA9IChMb2NhdGlvbkltcGwpbm9kZS5nZXRFbGVtZW50KCk7DQoJCQkJ DQoJCQkJaWYo
bm90aWZpY2F0aW9uLmdldEZlYXR1cmUoKSBpbnN0YW5jZW9mIEVBdHRyaWJ1 dGVJbXBsKSAN
CgkJCQl7DQoJCQkJCUVBdHRyaWJ1dGVJbXBsIGF0dHJpYnV0ZSA9IChFQXR0 cmlidXRlSW1w
bCkgbm90aWZpY2F0aW9uLmdldEZlYXR1cmUoKTsNCgkJCQkJaWYgKGF0dHJp YnV0ZS5nZXRO
YW1lKCkuZXF1YWxzKCJ4IikpIA0KCQkJCQl7DQoJCQkJICAgICAgICAgIG1v ZGVsLnNldFhQ
b3NpdGlvbihub3RpZmllci5nZXRYKCkpOw0KCQkJCSAgICB9IA0KCQkJCQll bHNlIGlmIChh
dHRyaWJ1dGUuZ2V0TmFtZSgpLmVxdWFscygieSIpKSANCgkJCQkJew0KCQkJ CSAgICAgICAg
ICBtb2RlbC5zZXRZUG9zaXRpb24obm90aWZpZXIuZ2V0WSgpKTsNCgkJCQkg ICAgfQ0KCQkJ
CX0NCgkJCX0NCgkJCS8vIGZvciB0aGUgY2FzZSwgd2hlbiBhIG5ldyB2YWx1 ZSBpcyBzZXQg
aW4gdGhlIHByb3BlcnRpZXMgb2YgTG9jYXRpb24NCgkJCWVsc2UgaWYobm90 aWZpY2F0aW9u
LmdldE5vdGlmaWVyKCkgaW5zdGFuY2VvZiBMb2NhdGlvbikNCgkJCXsNCgkJ CQlyZWZyZXNo
Qm91bmRzKCk7DQoJCQl9DQoJCX0NCgkJDQoJCXN1cGVyLmhhbmRsZU5vdGlm aWNhdGlvbkV2
ZW50KG5vdGlmaWNhdGlvbik7DQoJfQ0KCQ0KCS8qKg0KCSAqIEBnZW5lcmF0 ZWQgTk9UDQoJ
ICovDQoJcHJvdGVjdGVkIHZvaWQgcmVmcmVzaEJvdW5kcygpIHsNCgkJLy8g TWV0aG9kIGNh
bGxlZCBvdmVyIGhhbmRsZU5vdGlmaWNhdGlvbkV2ZW50KCkgd2hlbjoNCgkJ CS8vIGNoYW5n
ZSBvZiBBdHRyaWJ1dGVzICh4UG9zLHlQb3MsaUQpDQoJCQkJLy8gd2hlbiB4 UG9zL3lQb3Mg
aXMgY2hhbmdlZCA6IG1vdmUgZmlndXJlIHRvIG5ldyBjb29yZGluYXRlcw0K CQkvLyBNZXRo
b2QgY2FsbGVkIGRpcmVjdGx5IHdoZW4NCgkJCS8vIG5ldyBmaWd1cmUNCgkJ CS8vIGZpZ3Vy
ZSBtb3ZlZA0KCQkJCS8vIHZhbHVlcyBvZiBtb3ZlIHdlcmUgc2V0IGluc2lk ZSBvZiBoYW5k
bGVOb3RpZmljYXRpb25FdmVudA0KCQkJCS8vIGhlcmUgc2V0IHBsYWNlIGFj Y29yZGluZyB0
byB0aGUgdmFsdWVzIG9mIExvY2F0aW9uDQoJCQkvLyBmaWd1cmUgcmVzaXpl ZA0KCQkNCgkJ
UG9pbnQgbmV3UG9pbnQ7DQoJCXRyeSANCgkJew0KCQkJTG9jYXRpb24gbG9j ID0gKExvY2F0
aW9uKSB0aGlzLnJlc29sdmVTZW1hbnRpY0VsZW1lbnQoKTsNCgkJCWludCBu ZXdYID0gbG9j
LmdldFhQb3NpdGlvbigpOw0KCQkJaW50IG5ld1kgPSBsb2MuZ2V0WVBvc2l0 aW9uKCk7DQoJ
CQluZXdQb2ludCA9IG5ldyBQb2ludChuZXdYLCBuZXdZKTsNCgkJfSANCgkJ Y2F0Y2ggKENs
YXNzQ2FzdEV4Y2VwdGlvbiBjY2UpIA0KCQl7DQoJCQlpbnQgeCA9ICgoSW50 ZWdlcikgZ2V0
U3RydWN0dXJhbEZlYXR1cmVWYWx1ZShOb3RhdGlvblBhY2thZ2UuZUlOU1RB TkNFLmdldExv
Y2F0aW9uX1goKSkpLmludFZhbHVlKCk7DQoJCQlpbnQgeSA9ICgoSW50ZWdl cikgZ2V0U3Ry
dWN0dXJhbEZlYXR1cmVWYWx1ZShOb3RhdGlvblBhY2thZ2UuZUlOU1RBTkNF LmdldExvY2F0
aW9uX1koKSkpLmludFZhbHVlKCk7DQoJCQluZXdQb2ludCA9IG5ldyBQb2lu dCh4LCB5KTsN
CgkJfQ0KCQkNCgkJaW50IHdpZHRoID0gKChJbnRlZ2VyKSBnZXRTdHJ1Y3R1 cmFsRmVhdHVy
ZVZhbHVlKE5vdGF0aW9uUGFja2FnZS5lSU5TVEFOQ0UuZ2V0U2l6ZV9XaWR0 aCgpKSkuaW50
VmFsdWUoKTsNCgkJaW50IGhlaWdodCA9ICgoSW50ZWdlcikgZ2V0U3RydWN0 dXJhbEZlYXR1
cmVWYWx1ZShOb3RhdGlvblBhY2thZ2UuZUlOU1RBTkNFLmdldFNpemVfSGVp Z2h0KCkpKS5p
bnRWYWx1ZSgpOw0KCQlEaW1lbnNpb24gc2l6ZSA9IG5ldyBEaW1lbnNpb24o d2lkdGgsIGhl
aWdodCk7DQoJCQ0KCQkoKEdyYXBoaWNhbEVkaXRQYXJ0KSBnZXRQYXJlbnQo KSkuc2V0TGF5
b3V0Q29uc3RyYWludCh0aGlzLCBnZXRGaWd1cmUoKSwgbmV3IFJlY3Rhbmds ZShuZXdQb2lu
dCwgc2l6ZSkpOw0KCX0NCgkNCgkNCgkvKioNCgkgKiBAZ2VuZXJhdGVkIE5P VA0KCSAqIChp
ZGVhIGZvciB1cGRhdGUgInN0b2xlbiIgZnJvbSANCgkgKiBkZS5wdnMuZHNj LmVkaXRvci5k
aWFncmFtLnBhcnQuRHNjZWRpdG9yRGlhZ3JhbVVwZGF0ZUNvbW1hbmQuZXhl Y3V0ZShFeGVj
dXRpb25FdmVudCBldmVudCkpDQoJICovDQoJcHVibGljIHZvaWQgbXlGNUNv bW1hbmQoKSB7
DQoJCQ0KCQlmaW5hbCBFT2JqZWN0IG1vZGVsRWxlbWVudCA9ICgoVmlldykg KChFZGl0UGFy
dCkgdGhpcy5nZXRQYXJlbnQoKSkuZ2V0TW9kZWwoKSkuZ2V0RWxlbWVudCgp Ow0KCQkNCgkJ
Ly8gQnVpbGQgYSBzZXBhcmF0ZSBwcm9jZXNzDQoJCVJ1bm5hYmxlIHJ1bm5h YmxlID0gbmV3
IFJ1bm5hYmxlKCkgDQoJCXsNCgkJCUBPdmVycmlkZQ0KCQkJcHVibGljIHZv aWQgcnVuKCkg
ew0KCQkJCXRyeSB7DQoJCQkJCVRocmVhZC5zbGVlcCg1MDAwKTsNCgkJCQkJ DQoJCQkJCS8v
IHRoZSAiRjUtY29tbWFuZCINCgkJCQkJTGlzdCBlZGl0UG9saWNpZXMgPSBD YW5vbmljYWxF
ZGl0UG9saWN5LmdldFJlZ2lzdGVyZWRFZGl0UG9saWNpZXMobW9kZWxFbGVt ZW50KTsNCgkJ
CQkJDQoJCQkJCWZvciAoSXRlcmF0b3IgaXQgPSBlZGl0UG9saWNpZXMuaXRl cmF0b3IoKTsg
aXQuaGFzTmV4dCgpOykgew0KCQkJCQkJQ2Fub25pY2FsRWRpdFBvbGljeSBu ZXh0RWRpdFBv
bGljeSA9IChDYW5vbmljYWxFZGl0UG9saWN5KSBpdC5uZXh0KCk7DQoJCQkJ CQluZXh0RWRp
dFBvbGljeS5yZWZyZXNoKCk7DQoJCQkJCX0NCgkJCQkJDQoJCQkJfSBjYXRj aCAoSW50ZXJy
dXB0ZWRFeGNlcHRpb24gZSkgew0KCQkJCQllLnByaW50U3RhY2tUcmFjZSgp Ow0KCQkJCX0N
CgkJCX0NCgkJfTsNCgkJDQoJCS8vIFRoaXMgcnVucyB0aGUgcHJvY2VzcyBi dWlsdCBhYm92
ZSBpbiBhIHNlcGVyYXRlIHRocmVhZA0KCQl0cnkgew0KCQkJZ2V0RWRpdGlu Z0RvbWFpbigp
LnJ1bkV4Y2x1c2l2ZShydW5uYWJsZSk7DQoJCX0gY2F0Y2ggKEludGVycnVw dGVkRXhjZXB0
aW9uIGUpIHsNCgkJCWUucHJpbnRTdGFja1RyYWNlKCk7DQoJCX0NCgl9DQoJ DQoJDQoJLyoq
DQoJICogQGdlbmVyYXRlZA0KCSAqLw0KCXB1YmxpYyBjbGFzcyBMb2NhdGlv bkZpZ3VyZSBl
eHRlbmRzIFJvdW5kZWRSZWN0YW5nbGUgew0KDQoJCS8qKg0KCQkgKiBAZ2Vu ZXJhdGVkDQoJ
CSAqLw0KCQlwdWJsaWMgTG9jYXRpb25GaWd1cmUoKSB7DQoJCQl0aGlzLnNl dENvcm5lckRp
bWVuc2lvbnMobmV3IERpbWVuc2lvbihnZXRNYXBNb2RlKCkuRFB0b0xQKDgp LA0KCQkJCQln
ZXRNYXBNb2RlKCkuRFB0b0xQKDgpKSk7DQoJCQl0aGlzLnNldEZvcmVncm91 bmRDb2xvcihD
b2xvckNvbnN0YW50cy5ncmF5KTsNCgkJCXRoaXMuc2V0QmFja2dyb3VuZENv bG9yKENvbG9y
Q29uc3RhbnRzLmdyYXkpOw0KCQkJdGhpcy5zZXRQcmVmZXJyZWRTaXplKG5l dyBEaW1lbnNp
b24oZ2V0TWFwTW9kZSgpLkRQdG9MUCgyMCksDQoJCQkJCWdldE1hcE1vZGUo KS5EUHRvTFAo
MjApKSk7DQoJCX0NCg0KCQkvKioNCgkJICogQGdlbmVyYXRlZA0KCQkgKi8N CgkJcHJpdmF0
ZSBib29sZWFuIG15VXNlTG9jYWxDb29yZGluYXRlcyA9IGZhbHNlOw0KDQoJ CS8qKg0KCQkg
KiBAZ2VuZXJhdGVkDQoJCSAqLw0KCQlwcm90ZWN0ZWQgYm9vbGVhbiB1c2VM b2NhbENvb3Jk
aW5hdGVzKCkgew0KCQkJcmV0dXJuIG15VXNlTG9jYWxDb29yZGluYXRlczsN CgkJfQ0KDQoJ
CS8qKg0KCQkgKiBAZ2VuZXJhdGVkDQoJCSAqLw0KCQlwcm90ZWN0ZWQgdm9p ZCBzZXRVc2VM
b2NhbENvb3JkaW5hdGVzKGJvb2xlYW4gdXNlTG9jYWxDb29yZGluYXRlcykg ew0KCQkJbXlV
c2VMb2NhbENvb3JkaW5hdGVzID0gdXNlTG9jYWxDb29yZGluYXRlczsNCgkJ fQ0KDQoJfQ0K
DQp9DQo=
--------------080305070607040802090005--
Re: Changing between different Figures [message #215576 is a reply to message #215202] Fri, 16 January 2009 16:59 Go to previous messageGo to next message
Alexander Shatalin is currently offline Alexander ShatalinFriend
Messages: 2928
Registered: July 2009
Senior Member
Hello Cayla,

The code executing update command in a separate thread is definitely incorrect,
so it's better simply remove it. ;-)

While working on a code i got the following idea: try calling "return;" just
after myF5Command execution like this:

if(EditorPackage.Literals.LOCATION__NUMBER_OF_VEHICLES.equal s(feature))
{
myF5Command();
return;
}

-----------------
Alex Shatalin
Re: Changing between different Figures [message #215591 is a reply to message #215576] Fri, 16 January 2009 17:28 Go to previous messageGo to next message
Eclipse UserFriend
Originally posted by: cayla_sha.gmx.net

Whoohoo!!
It works!!
Thanks! Thank you so much!
*dance*
Re: Changing between different Figures [message #217157 is a reply to message #215591] Tue, 03 February 2009 16:09 Go to previous messageGo to next message
Eclipse UserFriend
Originally posted by: cayla_sha.gmx.net

Hello Alex,

I have 2 problems with the change between the EditParts:
- When it changes, it looses its selection. After the change, nothing is
selected on the diagram surface.
How can I prevent it from loosing its selection?

- When it changes, sometimes it looses its attached connections. Its a
graphical problem. When I press F5 the connection are again drawn.
Can I prevent this graphic-bug?

Thanks in advance!
Best wishes
Julia
Re: Changing between different Figures [message #217179 is a reply to message #217157] Tue, 03 February 2009 18:51 Go to previous messageGo to next message
Alexander Shatalin is currently offline Alexander ShatalinFriend
Messages: 2928
Registered: July 2009
Senior Member
Hello Cayla,

Just try to debug setSelection() method in an implementation of GraphicalViewer
returned from DiagramEditor.getGraphicalViewer() to see the reason of selection
change event.

In case of links you have to debug generated DiagramUpdater class.

-----------------
Alex Shatalin
Re: Changing between different Figures [message #217412 is a reply to message #217179] Thu, 05 February 2009 17:54 Go to previous messageGo to next message
Eclipse UserFriend
Originally posted by: cayla_sha.gmx.net

Hello Alex,

> Just try to debug setSelection() method in an implementation of
> GraphicalViewer returned from DiagramEditor.getGraphicalViewer() to
> see the reason of selection change event.

Um, well,...
I didn`t find a method that is called
"DiagramEditor.getGraphicalViewer()". The only method that I found was
" org.eclipse.gef.ui.parts.GraphicalEditor.getGraphicalViewer( ) ". I found
a class "org.eclipse.gmf.runtime.diagram.ui.parts.DiagramEditor". Did
you mean this class?
Or did you mean "...diagram.part.XXXDiagramEditor" in my own project?
There I found a method-call "getDiagramGraphicalViewer()". When I put a
breakpoint at this method-call, I see, that it returns an instance of
the type "DiagramGraphicalViewer", but I can`t look further into it,
because there`s no source-code for it. Besides, this method is only
called once when the diagram is opened.

And I didn`t find any implementations of GraphicalViewer.(only
org.eclipse.gef.ui.parts.GraphicalViewImpl, but I don`t think you meant
this. besides, I also can`t see this source-code.)
Did you mean "org.eclipse.gef.GraphicalViewer" or
" org.eclipse.gmf.runtime.diagram.ui.parts.IDiagramGraphicalVi ewer "?


> In case of links you have to debug generated DiagramUpdater class.

And with that you meant "...diagram.part.XXXDiagramUpdater" in my own
project, right? In that case luckily there was no other DiagramUpdater...

Thanks for your help!
Best wishes
Julia
Re: Changing between different Figures [message #217444 is a reply to message #217179] Fri, 06 February 2009 12:09 Go to previous messageGo to next message
Eclipse UserFriend
Originally posted by: cayla_sha.gmx.net

> In case of links you have to debug generated DiagramUpdater class.

I debugged this class and now I have a idea why the Connection is
disappearing.
There is this method
XXXDiagramUpdater.getShapesDiagram_79ContainedLinks. It`s called once at
the start of the diagram. When I make the first change on my diagram, so
that an EditPart changes, this method is called once (and that`s the
reason why it looses its connection). On all other changes it`s called
three times (and then it doesn`t loose its connection). When I press F5
it`s also called once (that`s the reason why the connection re-appears,
when I press F5).

I digged deeper into it: The connection isn`t drawn, because when the
above method is only called once, the method
ShapesDiagramCanonicalEditPolicy.createConnections is also called only
once. And this method doesn`t work for the first time, when an EditPart
changes, because then either source- or targetEditPart is null. Only on
the second call they`re both not null and the Connection can be drawn.

I digged even deeper :) and found out, that the first time only
myF5command() (remember it?) is called. The other times myF5command()
plus two-times CanonicalEditPolicy.handleNotificationEvent() are called.
They`re both called from DiagramEventBroker.fireNotification.

So now my question: What`s so special about the first change on the
diagram? Why isn`t the handleNotificationEvent() of the
CanonicalEditPolicy called the first time?

Thanks in advance!
Best wishes
Julia
Re: Changing between different Figures [message #217853 is a reply to message #217412] Mon, 09 February 2009 10:39 Go to previous messageGo to next message
Alexander Shatalin is currently offline Alexander ShatalinFriend
Messages: 2928
Registered: July 2009
Senior Member
Hello Cayla,

> "DiagramEditor.getGraphicalViewer()". The only method that I found was
> " org.eclipse.gef.ui.parts.GraphicalEditor.getGraphicalViewer( ) ". I
Sorry, this is the method I supposed to point to.

> Or did you mean "...diagram.part.XXXDiagramEditor" in my own project?
Right. GraphicalEditor is subclassed there.

> the type "DiagramGraphicalViewer", but I can`t look further into it,
> because there`s no source-code for it. Besides, this method is only
You can download all GMf sources from GMf website.

> called once when the diagram is opened.
You have to put a breakpoint into setSelection() method of the class returned
from getGraphicalViewer().

-----------------
Alex Shatalin
Re: Changing between different Figures [message #217859 is a reply to message #217444] Mon, 09 February 2009 10:42 Go to previous messageGo to next message
Alexander Shatalin is currently offline Alexander ShatalinFriend
Messages: 2928
Registered: July 2009
Senior Member
Hello Cayla,

> So now my question: What`s so special about the first change on the
> diagram? Why isn`t the handleNotificationEvent() of the
> CanonicalEditPolicy called the first time?
Nothing special. Probably corresponding notification was not fired by EMF
(something was not changed in the model..)

-----------------
Alex Shatalin
Re: Changing between different Figures [message #217959 is a reply to message #217853] Mon, 09 February 2009 14:42 Go to previous messageGo to next message
Eclipse UserFriend
Originally posted by: cayla_sha.gmx.net

Ok, thanks for the clarification :)

I debugged and found out the following:

....diagram.part.XXXDiagramEditor.configureGraphicalViewer() calls
org.eclipse.gmf.runtime.diagram.ui.parts.DiagramEditor.getDi agramGraphicalViewer().

This method calls
org.eclipse.gef.ui.parts.GraphicalEditor.getGraphicalViewer( ).

And it returns an instance of the class
org.eclipse.gmf.runtime.diagram.ui.parts.DiagramGraphicalVie wer. (I can
look into this class. It was my mistake. I only can`t look into the
class GraphicalEditor, because this is gef, not gmf.)

So DiagramGraphicalViewer is the class, that is returned from
getGraphicalViewer(). But it doesn`t have a method setSelection().
It has 4 different methods which are called when something with
selection happens:
When I click around on my diagram and select different EditParts it
behaves like this:
first fireSelectionChanged() is called once, and then
flushSelectionEvents(ISelection sel). In this method "Object[] array" is
defined. On every selection-change it has 81 entries (I did not have the
time yet to look at every entry...)

Now to the case, when the EditPart is changed:
It looks like the same event as when I delete a shape.
The only difference: the array only has 3 entries. That are the same
three entries, that are in the array normally on the first 3 places, but
where are the other 78 entries?


This is very interesting, but I can`t see, how this helps me with my
problem.
It seems like it looses the selection on the old EditPart (because it`s
deleted) and don`t get the selection on the new EditPart.
But it doesn`t complete the selection-change, like it does, when an
EditPart is deleted. After the EditPart is changed, nothing is selected,
not even the ShapesDiagramEditPart.

Perhaps I should programmatically select the new created EditPart? But I
don`t know, where I can grab it and I don`t know how to select an
EditPart programmatically.

I hope you have an idea. I can`t tell my users, that they have to click
again on the shape after they created the first vehicle...

Best wishes
Julia
Re: Changing between different Figures [message #217967 is a reply to message #217859] Mon, 09 February 2009 14:48 Go to previous messageGo to next message
Eclipse UserFriend
Originally posted by: cayla_sha.gmx.net

Uhm, well, and how can I bring it to fire the notification?

The strange thing is, that it`s fired everytime - except for the first time.


Alex Shatalin schrieb:
> Hello Cayla,
>
>> So now my question: What`s so special about the first change on the
>> diagram? Why isn`t the handleNotificationEvent() of the
>> CanonicalEditPolicy called the first time?
> Nothing special. Probably corresponding notification was not fired by
> EMF (something was not changed in the model..)
>
> -----------------
> Alex Shatalin
>
>
Re: Changing between different Figures [message #218088 is a reply to message #217959] Tue, 10 February 2009 10:54 Go to previous messageGo to next message
Alexander Shatalin is currently offline Alexander ShatalinFriend
Messages: 2928
Registered: July 2009
Senior Member
Hello Cayla,

> So DiagramGraphicalViewer is the class, that is returned from
> getGraphicalViewer(). But it doesn`t have a method setSelection().
This methos is in one of DiagramGraphicalViewer's superclasses: AbstractEditPartViewer.

> Perhaps I should programmatically select the new created EditPart? But
This can be an option - try calling setSelection for the DiagramGraphicalViewer.

> I hope you have an idea. I can`t tell my users, that they have to
> click again on the shape after they created the first vehicle...
Well, I can not develop this application instead of you :-)..
So, you have to study a way to solve these problems and I’ll be available
to answer any particular questions about GMF.

-----------------
Alex Shatalin
Re: Changing between different Figures [message #218284 is a reply to message #218088] Wed, 11 February 2009 14:56 Go to previous messageGo to next message
Eclipse UserFriend
Originally posted by: cayla_sha.gmx.net

Hello Alex!

>> Perhaps I should programmatically select the new created EditPart?
> This can be an option - try calling setSelection for the
> DiagramGraphicalViewer.

I have 2 problems with your suggestion:

1. I don`t even know how to call setSelection(). I can`t just say
getDiagramGraphicalViewer().setSelection(...). I need an instance of a
DiagramEditor or a DiagramWorkbechPart on which I can call
getDiagramGraphicalViewer(), so that it looks anything like that:
DiagramEditor.eInstance.getDiagramGraphicalViewer().setSelec tion(...).

How can I get such an instance?

I looked at the generated code to find a piece of code where the same
thing as I want to do is done. And I found something:
....diagram.part.XXXDiagramEditorUtil.selectElementsInDiagra m().
Unfortunately this method gets its instance of IDiagramWorkbenchPart
passed from anywhere else. Very unfortunately this method is never
called. I tried "Open Call Hierarchy" and put a Debug-Point into the
method, but nothing happened.


2. I have an idea, how I can grab the newly created EditPart: Perhaps
any other class could listen to changes of the diagram (like the
EditParts do) and when the data of Location changes it gets a notifier
that a Location changed. The notifier contains the ID of the
LocationImpl which changed. Then I "just" have to find the correspending
LocationEditPart to the LocationImpl on the diagram (is this possible?)
an select it. For that I would need a good place where I can implement
this. I looked at a lot of classes, but I don`t know where I should put
my code. Perhaps in XXXEditPartFactory or in ShapesDiagramEditPart?

Do you have a good idea for a class where I can put my code? Do you
think this idea will work? Is it possible to find an EditPart for an Impl?


Of course you can`t develop this application for me. I always spend a
lot of time on the code and on google and I think for days about the
problem until I write a message here. And I never ask for a whole
implementation.
Btw I always wondered: Is this part of your daily work to answer the
newsgroup (so are you paid for that) or do you do this in your leisure time?

Thanks in advance!
Best wishes
Julia
Re: Changing between different Figures [message #218470 is a reply to message #218284] Thu, 12 February 2009 12:55 Go to previous messageGo to next message
Alexander Shatalin is currently offline Alexander ShatalinFriend
Messages: 2928
Registered: July 2009
Senior Member
Hello Cayla,

AFAIR your original problem was: at the end of F5 (diagram update) execution
newly created diagram node (substituting another one with incorrect==obsolete
figure) was no selected -> diagram node loose selection as a result of property
modification.

During F5 execution old diagram node will be removed together with an EditPart
and new one will be created instead. This means, if the “old” EditPart was
selected before update command execution this EditPart will definitely loos
the selection (it will be removed from diagram). To correct this inconsistency
you have to modify F5 (diagram update process) to detect the fact that old
element was selected and select newly created one in accordance.

AFAICSee from the current templates, “populateViewProperties()” method (responsible
for placing newly created node into the same position as old one) will be
generated in one of the CanonicalEditPolicies (I suppose in the CanonicalEditPolicy
generated for the diagram element) and this is a part of the job done by
GMF generated for you. I suggest you to:
- locate CanonicalEditPolicy containing “populateViewProperties()” method
- ensure this method will be called on modifying the property of domain model
element forcing this element to be substituted by another one
- modify this method or any other methods around it which are responsible
for a CanonicalUpdate to select newly created diagram node.

With the node selection you can face some more problems – it can happen that
corresponding EditPart will not be created yet in the end of populateViewProperties()
(or diagram update) execution. In this case you have to write your code in
a way you “remember” the node which should be selected and select this node
just after corresponding EditPart creation. One of the possible solutions
in this situation will be to issue a “specific select” command which will
be executed in the end of update process (then corresponding EditPart will
be created). This is still not a full solution for your problem but at least,
I tried to highlight most important steps to some extend.

Concerning the process of locating/selecting appropriate EditPart – in the
CanonicalEditPolicy you have a reference to the corresponding EditPart (parent
of the “substituted element”) so I think you can easily locate newly created
EditPart (for “new” element) using a reference to it’s parent inside “specific
select” command. Note: you will not be able to find new EditPart before it
will be created, so it makes sense to “remember” parent EditPart inside a
“specific select” command and use this reference only then your command will
be executed (in the end of EditPart model update process).

Same with DiagramGraphicalViewer (or any other way to select a diagram element)
– I suppose it should be possible to find appropriate reference being inside
CanonicalEditPolicy to remember it inside “slecific select” command.

BTW, this functionality looks like a missing part in GMF-generated code (since
we do generate “populateViewProperties()”) so you can create a bugzilla entry
describing this problem (and proposed solution if it will be working).

> Btw I always wondered: Is this part of your daily work to answer the
> newsgroup (so are you paid for that) or do you do this in your leisure
> time?
Well, Borland is paying me for GMF development and newsgroup support is a
part of GMF development process. Except newsgroup I do have a really huge
TODO list of GMF framework improvements and rather limited time for it (just
5 working days a week :-)).

Anyway, I hope this posting will answer most of your questions and finally
will end up with the bugzilla request with proposed solution improving this
part of framework.
-----------------
Alex Shatalin
Re: Changing between different Figures [message #218742 is a reply to message #218470] Fri, 13 February 2009 13:56 Go to previous messageGo to next message
Eclipse UserFriend
Originally posted by: cayla_sha.gmx.net

Hello Alex,

Thanks for your detailed answer!
wow, this is very complex...

I found ShapesDiagramCanonicalEditPolicy.populateViewProperties() and
it`s called when the EditParts are substituted.
I already managed to get the DiagramGraphicalViewer and I can get the
EditPart to the newly created View.
But as you said: The EditPart isn`t yet created at the end of
populateViewProperties() or isOrphaned().

The "specific select" command at the end of the update process is a good
idea - but where is "the end of the update process"?
About the update process I just know, that if passes (after it was in
populateViewProperties()) the new XXXEditPart.createNodeFigure(). And
after that it`s just in gmf-classes which I can`t modify.
Where should I call or trigger my "specific select" command?

Thanks in advance!
Best wishes
Julia



Alex Shatalin schrieb:
> Hello Cayla,
>
> AFAIR your original problem was: at the end of F5 (diagram update)
> execution newly created diagram node (substituting another one with
> incorrect==obsolete figure) was no selected -> diagram node loose
> selection as a result of property modification.
>
> During F5 execution old diagram node will be removed together with an
> EditPart and new one will be created instead. This means, if the “old”
> EditPart was selected before update command execution this EditPart will
> definitely loos the selection (it will be removed from diagram). To
> correct this inconsistency you have to modify F5 (diagram update
> process) to detect the fact that old element was selected and select
> newly created one in accordance.
> AFAICSee from the current templates, “populateViewProperties()” method
> (responsible for placing newly created node into the same position as
> old one) will be generated in one of the CanonicalEditPolicies (I
> suppose in the CanonicalEditPolicy generated for the diagram element)
> and this is a part of the job done by GMF generated for you. I suggest
> you to:
> - locate CanonicalEditPolicy containing “populateViewProperties()”
> method - ensure this method will be called on modifying the property of
> domain model element forcing this element to be substituted by another one
> - modify this method or any other methods around it which are
> responsible for a CanonicalUpdate to select newly created diagram node.
>
> With the node selection you can face some more problems – it can happen
> that corresponding EditPart will not be created yet in the end of
> populateViewProperties() (or diagram update) execution. In this case you
> have to write your code in a way you “remember” the node which should be
> selected and select this node just after corresponding EditPart
> creation. One of the possible solutions in this situation will be to
> issue a “specific select” command which will be executed in the end of
> update process (then corresponding EditPart will be created). This is
> still not a full solution for your problem but at least, I tried to
> highlight most important steps to some extend.
> Concerning the process of locating/selecting appropriate EditPart – in
> the CanonicalEditPolicy you have a reference to the corresponding
> EditPart (parent of the “substituted element”) so I think you can easily
> locate newly created EditPart (for “new” element) using a reference to
> it’s parent inside “specific select” command. Note: you will not be able
> to find new EditPart before it will be created, so it makes sense to
> “remember” parent EditPart inside a “specific select” command and use
> this reference only then your command will be executed (in the end of
> EditPart model update process).
>
> Same with DiagramGraphicalViewer (or any other way to select a diagram
> element) – I suppose it should be possible to find appropriate reference
> being inside CanonicalEditPolicy to remember it inside “slecific select”
> command.
>
> BTW, this functionality looks like a missing part in GMF-generated code
> (since we do generate “populateViewProperties()”) so you can create a
> bugzilla entry describing this problem (and proposed solution if it will
> be working).
>> Btw I always wondered: Is this part of your daily work to answer the
>> newsgroup (so are you paid for that) or do you do this in your leisure
>> time?
> Well, Borland is paying me for GMF development and newsgroup support is
> a part of GMF development process. Except newsgroup I do have a really
> huge TODO list of GMF framework improvements and rather limited time for
> it (just 5 working days a week :-)).
> Anyway, I hope this posting will answer most of your questions and
> finally will end up with the bugzilla request with proposed solution
> improving this part of framework.
> -----------------
> Alex Shatalin
>
>
Re: Changing between different Figures [message #218791 is a reply to message #218742] Fri, 13 February 2009 15:11 Go to previous messageGo to next message
Alexander Shatalin is currently offline Alexander ShatalinFriend
Messages: 2928
Registered: July 2009
Senior Member
Hello Cayla,

> idea - but where is "the end of the update process"?
By debugging I found that EditParts will be created/deleted just after corresponding
View creation/deletion (parent EditPart is listening for a notification from
underlying View instance)
So, you can put your code into refreshSemanticChildren() method… you have
to collect necessary data before calling original implementation of this
method and execute “selection” code then original refreshSemanticChildren()
method implementation will be processed. At least if I’m not mistaken..

-----------------
Alex Shatalin
Re: Changing between different Figures [message #219083 is a reply to message #218791] Tue, 17 February 2009 12:38 Go to previous messageGo to next message
Eclipse UserFriend
Originally posted by: cayla_sha.gmx.net

Hello Alex,

Thanks for the idea! :) It almost works.

When I try it the first time after starting the diagram it doesn`t work,
but that's the same issue what causes the connections to disappear.

When I try it the next time, the newly created EditPart is selected (it
has the black border around it), but something's wrong:
When I click on another Property-Tab, then (of course) the
setInput-method of this Tab is called. setInput() receives an ISelection
which contains the right EditPart. But the call
getModel().getElement() on this EditPart fails, because the element is
null, but it should be a LocationImpl.


Perhaps I select the EditPart wrongly?
I did the following:

I put my code at the end of the method
....diagram.edit.policies.ShapesDiagramCanonicalEditPolicy.r efreshSemantic().
Because refreshSemantic() calls refreshSemanticChildren(). And the
method refreshSemanticChildren() is in the GMF-Class CanonicalEditPolicy
which I can`t modify.

This is the code that I put there:
DiagramGraphicalViewer dgv =
(DiagramGraphicalViewer)CmdeditorDiagramEditor.getInstance() .getDiagramGraphicalViewer();
Map editPartRegistry = dgv.getEditPartRegistry();
boolean ck = editPartRegistry.containsKey(rememberTheCreatedView);
if(ck)
{
EditPart createdEditPart =
(EditPart)editPartRegistry.get(rememberTheCreatedView);
dgv.setSelection(new StructuredSelection(createdEditPart));
}

For that I needed to do two other changes:
- in CmdeditorDiagramEditor I put the method getInstance and a Variable
"instance", which is set in the Constructor.
- in ShapesDiagramCanonicalEditPolicy I put the global Variable
rememberTheCreatedView, which is set in isOrphaned to remember the View,
which is created there.

When I debug this code all the variables have the right content. When I
look into createdEditPart the Variable element contains still the right
LocationImpl.

But why is the element of the selected EditPart missing later? What
happens to the selection?


Best wishes
Julia


Alex Shatalin schrieb:
> Hello Cayla,
>
>> idea - but where is "the end of the update process"?
> By debugging I found that EditParts will be created/deleted just after
> corresponding View creation/deletion (parent EditPart is listening for a
> notification from underlying View instance)
> So, you can put your code into refreshSemanticChildren() method… you
> have to collect necessary data before calling original implementation of
> this method and execute “selection” code then original
> refreshSemanticChildren() method implementation will be processed. At
> least if I’m not mistaken..
>
> -----------------
> Alex Shatalin
>
>
Re: Changing between different Figures [message #220064 is a reply to message #219083] Thu, 26 February 2009 10:09 Go to previous message
Eclipse UserFriend
Originally posted by: cayla_sha.gmx.net

Hello!

The issue is still not working.
The Selection seams un-completed when I select the EditPart
programmatically. It`s not the same as when I select a EditPart with a
Mouse-Click.

I debugged it a lot of times and I found out the following:
Both times (when I select it programmatically or when I select it with a
MouseClick) fireSelectionChanged() and flushSelectionEvents() are called
in DiagramGraphicalViewer. But when I select it programmativcally the
Variable "array" in flushSelectionEvents() has only 3 Entries, when I
select it with a MouseClick it has 81 Entries.
And one of the missing entries must cause the call of
org.eclipse.jface.viewers.ContentViewer.setInput(), which sets the input
for the Property-Tabs.
So when I select the EditPart programmatically this setInput()-method
isn`t called, and when the next time a PropertyTab asks for the input,
it gets the old input.

That all leads to the conclusion, that I select the EditPart wrongly
when I do it in my code. (you see my code and how I select the EditPart
in my former mail)
So how can I select it right?

Thanks for any ideas!
Best wishes
Julia

PS: The other issue, that the Connections disappear on the first
EditPart-Change, is still not working. I debugged it, too, and the only
thing I can see, is, that on the first change there are calls misssing.
All the other times everything is called perfectly, but on the first
time some events aren`t thrown. This looks to me like this is a GMF-Bug.
Previous Topic:Undo / Redo for whole Commandstack
Next Topic:modify duplicate action
Goto Forum:
  


Current Time: Thu Mar 28 14:11:27 GMT 2024

Powered by FUDForum. Page generated in 0.07401 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software

Back to the top