[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Newsgroup Home]
|
[news.eclipse.modeling.gmf] Re: Programmatically drag and drop
|
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örg
"Cherie Revells" <crevells@xxxxxxxxxx> wrote in message
news:eols34$mbo$1@xxxxxxxxxxxxxxxxxxxx
> 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@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:
>>>>>
>>