[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Newsgroup Home]
|
[news.eclipse.modeling.gmf] Re: Programmatically drag and drop
|
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:
>>>>
>>>
>>>
>