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

[Vlad Ciubotariu <vcciubot@xxxxxxxxxxxx>]

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:
>>>
>>
>>