Home » Modeling » EMF » Different Drag and Drop prepare methods
| Different Drag and Drop prepare methods [message #897758] |
Wed, 25 July 2012 08:27  |
 Markus G
Messages: 23
Registered: June 2012 |
Junior Member |
|
|
Hi,
I am still working on modifying my drag and drop behaviour.
My class has a URI attribute, and at the moment I want to adjust this URI field when creating a new item. One option to create a new item in my scenario is by drag&drop from another model. The URI consists of its container's URI plus its name, so I will need the container's information.
My first try (with help from this forum) was to adjust the InitializeCopyCommand, but the problem was that I couldn't access the new item's container from there.
I then adjusted the createDragAndDropCommand by first overriding the prepareDropCopyInsert method. This works perfectly, I can access the parent element (container) and adjust my URI. However, it only works if, after dragging the original item, I drop it at its final destination in the new model. Meaning, if I have an element which is to be the new container and already two children, if I drop the new item right between the two elements, it will adjust the URI perfectly fine. If I drop it right on the parent element which results in the new element being appended to this element's children, though, nothing happens.
I found out by debugging, that these two scenarios result in different methods being invoked. The second one I described does not invoke prepareDropCopyInsert, but prepareDropLinkInsert. Intuitively, my next step was to override that method analogously, because I can also access the new parent element from there (it's the collection parameter instead of the parent parameter in prepareDropCopyInsert). But to my surprise, the behavior is really different, because it not only edits the new element that's being created in the target model, but it edits the original item as well. That is, of course, something I do not want, since it ruins my consistent URI in the original element. The name prepareDropLinkInsert suggests that a link is being created instead of a copy, and maybe that's the problem, but in the end a new element is created in the new model, so I think it should be possible to realize my desired behavior.
I hope it's more or less understandable what my problem is and maybe someone has an idea how to solve this?
Thanks a lot!
Markus
|
|
|
| Re: Different Drag and Drop prepare methods [message #897804 is a reply to message #897758] |
Wed, 25 July 2012 09:25  |
Ed Merks
Messages: 31163
Registered: July 2009 |
Senior Member |
|
|
Markus,
Comments below.
On 25/07/2012 10:27 AM, Markus G wrote:
> Hi,
>
> I am still working on modifying my drag and drop behaviour. My class
> has a URI attribute, and at the moment I want to adjust this URI field
> when creating a new item. One option to create a new item in my
> scenario is by drag&drop from another model. The URI consists of its
> container's URI plus its name, so I will need the container's
> information.
>
> My first try (with help from this forum) was to adjust the
> InitializeCopyCommand, but the problem was that I couldn't access the
> new item's container from there.
No, you don't know that until you actually add it to the container.
>
> I then adjusted the createDragAndDropCommand by first overriding the
> prepareDropCopyInsert method.
Drag and drop kind of has to work the same as copy and paste or cut and
paste...
> This works perfectly, I can access the parent element (container) and
> adjust my URI. However, it only works if, after dragging the original
> item, I drop it at its final destination in the new model. Meaning, if
> I have an element which is to be the new container and already two
> children, if I drop the new item right between the two elements, it
> will adjust the URI perfectly fine. If I drop it right on the parent
> element which results in the new element being appended to this
> element's children, though, nothing happens.
> I found out by debugging, that these two scenarios result in different
> methods being invoked.
Yes.
> The second one I described does not invoke prepareDropCopyInsert, but
> prepareDropLinkInsert.
Doesn't that yield false because of this test?
dropCommand = AddCommand.create(domain, parent, null, collection,
index);
if (!analyzeForNonContainment(dropCommand))
{
Isn't it prepareDropCopyOn() that ultimately creates the command that
can be execute?
> Intuitively, my next step was to override that method analogously,
> because I can also access the new parent element from there (it's the
> collection parameter instead of the parent parameter in
> prepareDropCopyInsert). But to my surprise, the behavior is really
> different, because it not only edits the new element that's being
> created in the target model, but it edits the original item as well.
> That is, of course, something I do not want, since it ruins my
> consistent URI in the original element. The name prepareDropLinkInsert
> suggests that a link is being created instead of a copy, and maybe
> that's the problem, but in the end a new element is created in the new
> model, so I think it should be possible to realize my desired behavior.
I'd expect this to create a (non-containment) reference to an existing
unmodified element.
>
> I hope it's more or less understandable what my problem is and maybe
> someone has an idea how to solve this?
>
> Thanks a lot!
> Markus
|
|
|
Goto Forum:
Current Time: Fri Jun 05 20:32:48 GMT 2020
Powered by FUDForum. Page generated in 0.01614 seconds |
Search
Help
Register
Login
Home
