Home » Modeling » GMF (Graphical Modeling Framework) » Programmatically drag and drop
| Programmatically drag and drop [message #92826] |
Mon, 15 January 2007 12:16  |
Eclipse User |
|
|
|
Originally posted by: joerg.weinmann.iese.fraunhofer.de
Hi everybody,
I need some help with the various Request subclasses of GMF-runtime.
In my EMF model the class "Component" has a reference "contains" to itself,
so that a Component can contain several other "Components". I already have a
GMF-generated editor for my model.
So for example, let C_A be a Component which contains Components C_A1 and
C_A2. And let C_B be an other Component.
What I want to do is programmatically move C_A1 and C_A2 to C_B, so that C_B
contains C_A1 and C_A2 and C_A is "empty".
I already tried SetRequest&DestroyRequest and MoveRequest, but it is not
working like I exepected it. So basically all I want to do is simulate a d&d
programmtically.
My underlying gmf model loks like this:
<?xml version="1.0" encoding="UTF-8"?>
<ecore:EPackage xmi:version="2.0"
xmlns:xmi="http://www.omg.org/XMI"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:ecore="http://www.eclipse.org/emf/2002/Ecore"
name="ConnectorComponent"
nsURI="www.iese.fraunhofer.de/ConnectorComponent" nsPrefix="cmpnt">
<eClassifiers xsi:type="ecore:EClass" name="AbstractComponent"
abstract="true" eSuperTypes="#//ArchitecturalElements">
<eStructuralFeatures xsi:type="ecore:EReference" name="contains"
upperBound="-1"
eType="#//AbstractComponent" containment="true"/>
<eStructuralFeatures xsi:type="ecore:EAttribute" name="name"
eType="ecore:EDataType http://www.eclipse.org/emf/2002/Ecore#//EString"/>
</eClassifiers>
<eClassifiers xsi:type="ecore:EClass" name="AbstractConnector"
abstract="true" eSuperTypes="#//ArchitecturalElements">
<eStructuralFeatures xsi:type="ecore:EReference" name="source"
lowerBound="1"
eType="#//AbstractComponent"/>
<eStructuralFeatures xsi:type="ecore:EReference" name="target"
lowerBound="1"
eType="#//AbstractComponent"/>
<eStructuralFeatures xsi:type="ecore:EAttribute" name="name"
eType="ecore:EDataType http://www.eclipse.org/emf/2002/Ecore#//EString"/>
</eClassifiers>
<eClassifiers xsi:type="ecore:EClass" name="ArchitecturalDescription">
<eStructuralFeatures xsi:type="ecore:EReference" name="has"
upperBound="-1" eType="#//ArchitecturalElements"
containment="true"/>
</eClassifiers>
<eClassifiers xsi:type="ecore:EClass" name="ArchitecturalElements"
abstract="true"/>
<eClassifiers xsi:type="ecore:EClass" name="Connector"
eSuperTypes="#//AbstractConnector"/>
<eClassifiers xsi:type="ecore:EClass" name="Component"
eSuperTypes="#//AbstractComponent"/>
</ecore:EPackage>
Input:
|
|
| | | | |
| Re: Programmatically drag and drop [message #93320 is a reply to message #93229] |
Tue, 16 January 2007 11:05  |
| Eclipse User |
|
|
|
Originally posted by: vcciubot.uwaterloo.ca
Are the containers you are moving canonical? Meaning, do the compartments
have canonical edit policies installed? If so you can put a break point in
CanonicalEditPolicy#shouldHandleNotificationEvent to see whether it
returns true after your command gets executed.
In my case I override it like this:
protected boolean shouldHandleNotificationEvent(Notification event) {
Object element = event.getNotifier();
if (element instanceof EObject && !(element instanceof View)
&& NotificationUtil.isSlotModified(event))
return true;
return super.shouldHandleNotificationEvent(event);
}
This might trigger the update in your case too. I don't remember why I
added this code, but I think I was having a similar problem.
-vlad
On Tue, 16 Jan 2007 14:16:04 +0100, Jörg Weinmann wrote:
> I modified my action like you advised, but the result is the same like
> before: the underlying data model is correctly changed, but the visual
> representation is not correctly updated.
>
>
> MoveRequest moveRequest = new
> MoveRequest(selectedElement.getEditingDomain(), createdModelElement,
> listOfContainedElements);
> MoveElementsCommand moveCommand = new MoveElementsCommand(moveRequest);
>
> IOperationHistory history = OperationHistoryFactory.getOperationHistory();
> try {
> history.execute(moveCommand, new NullProgressMonitor(), null);
> } catch (ExecutionException e) {
> // TODO Auto-generated catch block
> e.printStackTrace();
> }
>
> Cheers,
> Jörg
>
>
>
> "Jörg Weinmann" <joerg.weinmann@iese.fraunhofer.de> wrote in message
> news:eoibgm$3q6$1@utils.eclipse.org...
>> Thanks,
>>
>> I think what you described already exitsts:
>> org.eclipse.gmf.runtime.emf.type.core.commands.MoveElementsC ommand
>>
>> My code looks like this:
>> MoveRequest moveRequest = new
>> MoveRequest(selectedElement.getEditingDomain(), createdModelElement,
>> listOfContainedElements);
>>
>> MoveElementsCommand moveCommand = new MoveElementsCommand(moveRequest);
>>
>>
>> selectedElement.getDiagramEditDomain().getDiagramCommandStac k().execute(new
>> ICommandProxy(moveCommand));
>>
>>
>> But the visuals don't get updated. I have to close and reopen the diagram
>> to see the changes. Is there a way to force a refresh on the whole
>> diagram?
>>
>> Cheers,
>> Jörg
>>
>>
>> "Vlad Ciubotariu" <vcciubot@uwaterloo.ca> wrote in message
>> news:pan.2007.01.15.17.29.52.516113@uwaterloo.ca...
>>> The easiest way would be to create your abstract transactional command
>>> that adds one component to a different container. This is equivalent of a
>>> move since EMF will remove it from its previous container.
>>>
>>> Execute that command on the operation history.
>>>
>>> -vlad
>>>
>>> On Mon, 15 Jan 2007 18:16:51 +0100, Jörg Weinmann wrote:
>>>
>>>> Hi everybody,
>>>>
>>>> I need some help with the various Request subclasses of GMF-runtime.
>>>> In my EMF model the class "Component" has a reference "contains" to
>>>> itself,
>>>> so that a Component can contain several other "Components". I already
>>>> have a
>>>> GMF-generated editor for my model.
>>>>
>>>> So for example, let C_A be a Component which contains Components C_A1
>>>> and
>>>> C_A2. And let C_B be an other Component.
>>>> What I want to do is programmatically move C_A1 and C_A2 to C_B, so that
>>>> C_B
>>>> contains C_A1 and C_A2 and C_A is "empty".
>>>>
>>>> I already tried SetRequest&DestroyRequest and MoveRequest, but it is not
>>>> working like I exepected it. So basically all I want to do is simulate a
>>>> d&d
>>>> programmtically.
>>>>
>>>>
>>>> My underlying gmf model loks like this:
>>>> <?xml version="1.0" encoding="UTF-8"?>
>>>> <ecore:EPackage xmi:version="2.0"
>>>> xmlns:xmi="http://www.omg.org/XMI"
>>>> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
>>>> xmlns:ecore="http://www.eclipse.org/emf/2002/Ecore"
>>>> name="ConnectorComponent"
>>>> nsURI="www.iese.fraunhofer.de/ConnectorComponent" nsPrefix="cmpnt">
>>>> <eClassifiers xsi:type="ecore:EClass" name="AbstractComponent"
>>>> abstract="true" eSuperTypes="#//ArchitecturalElements">
>>>> <eStructuralFeatures xsi:type="ecore:EReference" name="contains"
>>>> upperBound="-1"
>>>> eType="#//AbstractComponent" containment="true"/>
>>>> <eStructuralFeatures xsi:type="ecore:EAttribute" name="name"
>>>> eType="ecore:EDataType
>>>> http://www.eclipse.org/emf/2002/Ecore#//EString"/>
>>>> </eClassifiers>
>>>> <eClassifiers xsi:type="ecore:EClass" name="AbstractConnector"
>>>> abstract="true" eSuperTypes="#//ArchitecturalElements">
>>>> <eStructuralFeatures xsi:type="ecore:EReference" name="source"
>>>> lowerBound="1"
>>>> eType="#//AbstractComponent"/>
>>>> <eStructuralFeatures xsi:type="ecore:EReference" name="target"
>>>> lowerBound="1"
>>>> eType="#//AbstractComponent"/>
>>>> <eStructuralFeatures xsi:type="ecore:EAttribute" name="name"
>>>> eType="ecore:EDataType
>>>> http://www.eclipse.org/emf/2002/Ecore#//EString"/>
>>>> </eClassifiers>
>>>> <eClassifiers xsi:type="ecore:EClass" name="ArchitecturalDescription">
>>>> <eStructuralFeatures xsi:type="ecore:EReference" name="has"
>>>> upperBound="-1" eType="#//ArchitecturalElements"
>>>> containment="true"/>
>>>> </eClassifiers>
>>>> <eClassifiers xsi:type="ecore:EClass" name="ArchitecturalElements"
>>>> abstract="true"/>
>>>> <eClassifiers xsi:type="ecore:EClass" name="Connector"
>>>> eSuperTypes="#//AbstractConnector"/>
>>>> <eClassifiers xsi:type="ecore:EClass" name="Component"
>>>> eSuperTypes="#//AbstractComponent"/>
>>>> </ecore:EPackage>
>>>>
>>>> Input:
>>>
>>
>>
|
|
| |
| Re: Programmatically drag and drop [message #93713 is a reply to message #93358] |
Wed, 17 January 2007 14:05 |
| Eclipse User |
|
|
|
Jörg,
This seems to work fine in the Taipan Example -- you can move small and
large items from one ship to another. I would suggest looking to see
how it is accomplished here.
Regards,
Cherie
Jörg Weinmann wrote:
> I think all container elements are cononical, because they are generated by
> GMF. I've put a break point in the shouldHandleNotificationEvent method, but
> it seems that it always returns true. I also tried to refresh the diagram
> elements manually, but it also doesn't work. Are you sure that the
> MoveRequest is the right request? AFAIU "REQ_MOVE" means moving children in
> the same parent container, but I want to "deparent" them and add them to an
> other parent. On the other hand, the underlying data structure gets
> correctly updated, so MoveRequest could be right.
>
> I have to admit I am a little frustrated at the moment. I would really
> appriciate more hints to a solution. Thanks.
>
> Cheers,
> Jörg
>
>
>
> "Vlad Ciubotariu" <vcciubot@uwaterloo.ca> wrote in message
> news:pan.2007.01.16.16.05.17.340180@uwaterloo.ca...
>> Are the containers you are moving canonical? Meaning, do the compartments
>> have canonical edit policies installed? If so you can put a break point in
>> CanonicalEditPolicy#shouldHandleNotificationEvent to see whether it
>> returns true after your command gets executed.
>>
>> In my case I override it like this:
>>
>> protected boolean shouldHandleNotificationEvent(Notification event) {
>> Object element = event.getNotifier();
>>
>> if (element instanceof EObject && !(element instanceof View)
>> && NotificationUtil.isSlotModified(event))
>> return true;
>>
>> return super.shouldHandleNotificationEvent(event);
>>
>> }
>>
>> This might trigger the update in your case too. I don't remember why I
>> added this code, but I think I was having a similar problem.
>>
>> -vlad
>>
>>
>> On Tue, 16 Jan 2007 14:16:04 +0100, Jörg Weinmann wrote:
>>
>>> I modified my action like you advised, but the result is the same like
>>> before: the underlying data model is correctly changed, but the visual
>>> representation is not correctly updated.
>>>
>>>
>>> MoveRequest moveRequest = new
>>> MoveRequest(selectedElement.getEditingDomain(), createdModelElement,
>>> listOfContainedElements);
>>> MoveElementsCommand moveCommand = new MoveElementsCommand(moveRequest);
>>>
>>> IOperationHistory history =
>>> OperationHistoryFactory.getOperationHistory();
>>> try {
>>> history.execute(moveCommand, new NullProgressMonitor(), null);
>>> } catch (ExecutionException e) {
>>> // TODO Auto-generated catch block
>>> e.printStackTrace();
>>> }
>>>
>>> Cheers,
>>> Jörg
>>>
>>>
>>>
>>> "Jörg Weinmann" <joerg.weinmann@iese.fraunhofer.de> wrote in message
>>> news:eoibgm$3q6$1@utils.eclipse.org...
>>>> Thanks,
>>>>
>>>> I think what you described already exitsts:
>>>> org.eclipse.gmf.runtime.emf.type.core.commands.MoveElementsC ommand
>>>>
>>>> My code looks like this:
>>>> MoveRequest moveRequest = new
>>>> MoveRequest(selectedElement.getEditingDomain(), createdModelElement,
>>>> listOfContainedElements);
>>>>
>>>> MoveElementsCommand moveCommand = new MoveElementsCommand(moveRequest);
>>>>
>>>>
>>>> selectedElement.getDiagramEditDomain().getDiagramCommandStac k().execute(new
>>>> ICommandProxy(moveCommand));
>>>>
>>>>
>>>> But the visuals don't get updated. I have to close and reopen the
>>>> diagram
>>>> to see the changes. Is there a way to force a refresh on the whole
>>>> diagram?
>>>>
>>>> Cheers,
>>>> Jörg
>>>>
>>>>
>>>> "Vlad Ciubotariu" <vcciubot@uwaterloo.ca> wrote in message
>>>> news:pan.2007.01.15.17.29.52.516113@uwaterloo.ca...
>>>>> The easiest way would be to create your abstract transactional command
>>>>> that adds one component to a different container. This is equivalent of
>>>>> a
>>>>> move since EMF will remove it from its previous container.
>>>>>
>>>>> Execute that command on the operation history.
>>>>>
>>>>> -vlad
>>>>>
>>>>> On Mon, 15 Jan 2007 18:16:51 +0100, Jörg Weinmann wrote:
>>>>>
>>>>>> Hi everybody,
>>>>>>
>>>>>> I need some help with the various Request subclasses of GMF-runtime.
>>>>>> In my EMF model the class "Component" has a reference "contains" to
>>>>>> itself,
>>>>>> so that a Component can contain several other "Components". I already
>>>>>> have a
>>>>>> GMF-generated editor for my model.
>>>>>>
>>>>>> So for example, let C_A be a Component which contains Components C_A1
>>>>>> and
>>>>>> C_A2. And let C_B be an other Component.
>>>>>> What I want to do is programmatically move C_A1 and C_A2 to C_B, so
>>>>>> that
>>>>>> C_B
>>>>>> contains C_A1 and C_A2 and C_A is "empty".
>>>>>>
>>>>>> I already tried SetRequest&DestroyRequest and MoveRequest, but it is
>>>>>> not
>>>>>> working like I exepected it. So basically all I want to do is simulate
>>>>>> a
>>>>>> d&d
>>>>>> programmtically.
>>>>>>
>>>>>>
>>>>>> My underlying gmf model loks like this:
>>>>>> <?xml version="1.0" encoding="UTF-8"?>
>>>>>> <ecore:EPackage xmi:version="2.0"
>>>>>> xmlns:xmi="http://www.omg.org/XMI"
>>>>>> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
>>>>>> xmlns:ecore="http://www.eclipse.org/emf/2002/Ecore"
>>>>>> name="ConnectorComponent"
>>>>>> nsURI="www.iese.fraunhofer.de/ConnectorComponent"
>>>>>> nsPrefix="cmpnt">
>>>>>> <eClassifiers xsi:type="ecore:EClass" name="AbstractComponent"
>>>>>> abstract="true" eSuperTypes="#//ArchitecturalElements">
>>>>>> <eStructuralFeatures xsi:type="ecore:EReference" name="contains"
>>>>>> upperBound="-1"
>>>>>> eType="#//AbstractComponent" containment="true"/>
>>>>>> <eStructuralFeatures xsi:type="ecore:EAttribute" name="name"
>>>>>> eType="ecore:EDataType
>>>>>> http://www.eclipse.org/emf/2002/Ecore#//EString"/>
>>>>>> </eClassifiers>
>>>>>> <eClassifiers xsi:type="ecore:EClass" name="AbstractConnector"
>>>>>> abstract="true" eSuperTypes="#//ArchitecturalElements">
>>>>>> <eStructuralFeatures xsi:type="ecore:EReference" name="source"
>>>>>> lowerBound="1"
>>>>>> eType="#//AbstractComponent"/>
>>>>>> <eStructuralFeatures xsi:type="ecore:EReference" name="target"
>>>>>> lowerBound="1"
>>>>>> eType="#//AbstractComponent"/>
>>>>>> <eStructuralFeatures xsi:type="ecore:EAttribute" name="name"
>>>>>> eType="ecore:EDataType
>>>>>> http://www.eclipse.org/emf/2002/Ecore#//EString"/>
>>>>>> </eClassifiers>
>>>>>> <eClassifiers xsi:type="ecore:EClass"
>>>>>> name="ArchitecturalDescription">
>>>>>> <eStructuralFeatures xsi:type="ecore:EReference" name="has"
>>>>>> upperBound="-1" eType="#//ArchitecturalElements"
>>>>>> containment="true"/>
>>>>>> </eClassifiers>
>>>>>> <eClassifiers xsi:type="ecore:EClass" name="ArchitecturalElements"
>>>>>> abstract="true"/>
>>>>>> <eClassifiers xsi:type="ecore:EClass" name="Connector"
>>>>>> eSuperTypes="#//AbstractConnector"/>
>>>>>> <eClassifiers xsi:type="ecore:EClass" name="Component"
>>>>>> eSuperTypes="#//AbstractComponent"/>
>>>>>> </ecore:EPackage>
>>>>>>
>>>>>> Input:
>>>>
>
>
|
|
|
| Re: Programmatically drag and drop [message #93743 is a reply to message #93358] |
Wed, 17 January 2007 14:54 |
| Eclipse User |
|
|
|
Originally posted by: vcciubot.uwaterloo.ca
If the model gets updated, the problem lies with the canonical policies.
Try the following experiment, try first to move programmatically one child
from one parent to another.
Then try to add a child through the user interface. Will this trigger an
update for your programmatic action? If it does, the policy doesn't
refresh when you make your change programmatically.
Another check to see whether it's the CanonicalPolicy's fault is to
breakpoint
protected List getSemanticChildrenList(); in the modified containers.
vlad
On Tue, 16 Jan 2007 17:30:24 +0100, Jörg Weinmann wrote:
> I think all container elements are cononical, because they are generated by
> GMF. I've put a break point in the shouldHandleNotificationEvent method, but
> it seems that it always returns true. I also tried to refresh the diagram
> elements manually, but it also doesn't work. Are you sure that the
> MoveRequest is the right request? AFAIU "REQ_MOVE" means moving children in
> the same parent container, but I want to "deparent" them and add them to an
> other parent. On the other hand, the underlying data structure gets
> correctly updated, so MoveRequest could be right.
>
> I have to admit I am a little frustrated at the moment. I would really
> appriciate more hints to a solution. Thanks.
>
> Cheers,
> Jörg
>
>
>
> "Vlad Ciubotariu" <vcciubot@uwaterloo.ca> wrote in message
> news:pan.2007.01.16.16.05.17.340180@uwaterloo.ca...
>> Are the containers you are moving canonical? Meaning, do the compartments
>> have canonical edit policies installed? If so you can put a break point in
>> CanonicalEditPolicy#shouldHandleNotificationEvent to see whether it
>> returns true after your command gets executed.
>>
>> In my case I override it like this:
>>
>> protected boolean shouldHandleNotificationEvent(Notification event) {
>> Object element = event.getNotifier();
>>
>> if (element instanceof EObject && !(element instanceof View)
>> && NotificationUtil.isSlotModified(event))
>> return true;
>>
>> return super.shouldHandleNotificationEvent(event);
>>
>> }
>>
>> This might trigger the update in your case too. I don't remember why I
>> added this code, but I think I was having a similar problem.
>>
>> -vlad
>>
>>
>> On Tue, 16 Jan 2007 14:16:04 +0100, Jörg Weinmann wrote:
>>
>>> I modified my action like you advised, but the result is the same like
>>> before: the underlying data model is correctly changed, but the visual
>>> representation is not correctly updated.
>>>
>>>
>>> MoveRequest moveRequest = new
>>> MoveRequest(selectedElement.getEditingDomain(), createdModelElement,
>>> listOfContainedElements);
>>> MoveElementsCommand moveCommand = new MoveElementsCommand(moveRequest);
>>>
>>> IOperationHistory history =
>>> OperationHistoryFactory.getOperationHistory();
>>> try {
>>> history.execute(moveCommand, new NullProgressMonitor(), null);
>>> } catch (ExecutionException e) {
>>> // TODO Auto-generated catch block
>>> e.printStackTrace();
>>> }
>>>
>>> Cheers,
>>> Jörg
>>>
>>>
>>>
>>> "Jörg Weinmann" <joerg.weinmann@iese.fraunhofer.de> wrote in message
>>> news:eoibgm$3q6$1@utils.eclipse.org...
>>>> Thanks,
>>>>
>>>> I think what you described already exitsts:
>>>> org.eclipse.gmf.runtime.emf.type.core.commands.MoveElementsC ommand
>>>>
>>>> My code looks like this:
>>>> MoveRequest moveRequest = new
>>>> MoveRequest(selectedElement.getEditingDomain(), createdModelElement,
>>>> listOfContainedElements);
>>>>
>>>> MoveElementsCommand moveCommand = new MoveElementsCommand(moveRequest);
>>>>
>>>>
>>>> selectedElement.getDiagramEditDomain().getDiagramCommandStac k().execute(new
>>>> ICommandProxy(moveCommand));
>>>>
>>>>
>>>> But the visuals don't get updated. I have to close and reopen the
>>>> diagram
>>>> to see the changes. Is there a way to force a refresh on the whole
>>>> diagram?
>>>>
>>>> Cheers,
>>>> Jörg
>>>>
>>>>
>>>> "Vlad Ciubotariu" <vcciubot@uwaterloo.ca> wrote in message
>>>> news:pan.2007.01.15.17.29.52.516113@uwaterloo.ca...
>>>>> The easiest way would be to create your abstract transactional command
>>>>> that adds one component to a different container. This is equivalent of
>>>>> a
>>>>> move since EMF will remove it from its previous container.
>>>>>
>>>>> Execute that command on the operation history.
>>>>>
>>>>> -vlad
>>>>>
>>>>> On Mon, 15 Jan 2007 18:16:51 +0100, Jörg Weinmann wrote:
>>>>>
>>>>>> Hi everybody,
>>>>>>
>>>>>> I need some help with the various Request subclasses of GMF-runtime.
>>>>>> In my EMF model the class "Component" has a reference "contains" to
>>>>>> itself,
>>>>>> so that a Component can contain several other "Components". I already
>>>>>> have a
>>>>>> GMF-generated editor for my model.
>>>>>>
>>>>>> So for example, let C_A be a Component which contains Components C_A1
>>>>>> and
>>>>>> C_A2. And let C_B be an other Component.
>>>>>> What I want to do is programmatically move C_A1 and C_A2 to C_B, so
>>>>>> that
>>>>>> C_B
>>>>>> contains C_A1 and C_A2 and C_A is "empty".
>>>>>>
>>>>>> I already tried SetRequest&DestroyRequest and MoveRequest, but it is
>>>>>> not
>>>>>> working like I exepected it. So basically all I want to do is simulate
>>>>>> a
>>>>>> d&d
>>>>>> programmtically.
>>>>>>
>>>>>>
>>>>>> My underlying gmf model loks like this:
>>>>>> <?xml version="1.0" encoding="UTF-8"?>
>>>>>> <ecore:EPackage xmi:version="2.0"
>>>>>> xmlns:xmi="http://www.omg.org/XMI"
>>>>>> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
>>>>>> xmlns:ecore="http://www.eclipse.org/emf/2002/Ecore"
>>>>>> name="ConnectorComponent"
>>>>>> nsURI="www.iese.fraunhofer.de/ConnectorComponent"
>>>>>> nsPrefix="cmpnt">
>>>>>> <eClassifiers xsi:type="ecore:EClass" name="AbstractComponent"
>>>>>> abstract="true" eSuperTypes="#//ArchitecturalElements">
>>>>>> <eStructuralFeatures xsi:type="ecore:EReference" name="contains"
>>>>>> upperBound="-1"
>>>>>> eType="#//AbstractComponent" containment="true"/>
>>>>>> <eStructuralFeatures xsi:type="ecore:EAttribute" name="name"
>>>>>> eType="ecore:EDataType
>>>>>> http://www.eclipse.org/emf/2002/Ecore#//EString"/>
>>>>>> </eClassifiers>
>>>>>> <eClassifiers xsi:type="ecore:EClass" name="AbstractConnector"
>>>>>> abstract="true" eSuperTypes="#//ArchitecturalElements">
>>>>>> <eStructuralFeatures xsi:type="ecore:EReference" name="source"
>>>>>> lowerBound="1"
>>>>>> eType="#//AbstractComponent"/>
>>>>>> <eStructuralFeatures xsi:type="ecore:EReference" name="target"
>>>>>> lowerBound="1"
>>>>>> eType="#//AbstractComponent"/>
>>>>>> <eStructuralFeatures xsi:type="ecore:EAttribute" name="name"
>>>>>> eType="ecore:EDataType
>>>>>> http://www.eclipse.org/emf/2002/Ecore#//EString"/>
>>>>>> </eClassifiers>
>>>>>> <eClassifiers xsi:type="ecore:EClass"
>>>>>> name="ArchitecturalDescription">
>>>>>> <eStructuralFeatures xsi:type="ecore:EReference" name="has"
>>>>>> upperBound="-1" eType="#//ArchitecturalElements"
>>>>>> containment="true"/>
>>>>>> </eClassifiers>
>>>>>> <eClassifiers xsi:type="ecore:EClass" name="ArchitecturalElements"
>>>>>> abstract="true"/>
>>>>>> <eClassifiers xsi:type="ecore:EClass" name="Connector"
>>>>>> eSuperTypes="#//AbstractConnector"/>
>>>>>> <eClassifiers xsi:type="ecore:EClass" name="Component"
>>>>>> eSuperTypes="#//AbstractComponent"/>
>>>>>> </ecore:EPackage>
>>>>>>
>>>>>> Input:
>>>>>
>>>>
>>>>
>>
|
|
|
| Re: Programmatically drag and drop [message #99673 is a reply to message #93713] |
Wed, 31 January 2007 11:23 |
| Eclipse User |
|
|
|
Originally posted by: joerg.weinmann.iese.fraunhofer.de
Thanks for your help Vlad and Cherie,
as it seems my problem lies deeper. I wanted to trigger a move which was ok
in the domain model but was not specified in the gmfmap model. After the
execution of my command the view was corrupted. I think I will have to
modify my gmfmap model.
Cheers,
J
|
|
|
Goto Forum:
Current Time: Tue Jul 15 03:16:33 EDT 2025
Powered by FUDForum. Page generated in 0.18703 seconds |
Home