[news.eclipse.modeling.gmf] Re: Programmatically drag and drop

[Vlad Ciubotariu <vcciubot@xxxxxxxxxxxx>]

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@xxxxxxxxxxxx> wrote in message 
> news:pan.2007.01.16.16.05.17.340180@xxxxxxxxxxxxxxx
>> 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@xxxxxxxxxxxxxxxxxx> wrote in message
>>> news:eoibgm$3q6$1@xxxxxxxxxxxxxxxxxxxx
>>>> Thanks,
>>>>
>>>> I think what you described already exitsts:
>>>> org.eclipse.gmf.runtime.emf.type.core.commands.MoveElementsCommand
>>>>
>>>> My code looks like this:
>>>> MoveRequest moveRequest = new
>>>> MoveRequest(selectedElement.getEditingDomain(), createdModelElement,
>>>> listOfContainedElements);
>>>>
>>>> MoveElementsCommand moveCommand = new MoveElementsCommand(moveRequest);
>>>>
>>>>
>>>> selectedElement.getDiagramEditDomain().getDiagramCommandStack().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@xxxxxxxxxxxx> wrote in message
>>>> news:pan.2007.01.15.17.29.52.516113@xxxxxxxxxxxxxxx
>>>>> 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:
>>>>>
>>>>
>>>>
>>