Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Archived » BPMN Modeler » Copy-Paste
Copy-Paste [message #5735] Wed, 14 January 2009 13:21 Go to next message
Eclipse UserFriend
Originally posted by: tobk42.gmx.de

Hello,

I noticed that in the STP-BPMN editor copy-paste works just fine, which
ist not as naturally for a GMF based editor. Could you please point me
to the part(s) of the code responsible for this feature, or is it just a
matter of configuration or even just the right (maybe outdated?) GMF
version?

Kind regards,
Tobias
Re: Copy-Paste [message #5753 is a reply to message #5735] Wed, 14 January 2009 17:45 Go to previous messageGo to next message
Eclipse UserFriend
Originally posted by: atoulme.intalio.com

Each GMF based editor needs some work to make copy/paste work like it
should be. The problem is that there is more than one way to copy stuff,
do you want to copy the view, the semantic element, where do you paste,
how do you deal with connected elements, etc.

So you need to do a lot of little tweaks.

Look for BpmnClipboardSupport for example.

Thanks,

Antoine

Tobias wrote:
> Hello,
>
> I noticed that in the STP-BPMN editor copy-paste works just fine, which
> ist not as naturally for a GMF based editor. Could you please point me
> to the part(s) of the code responsible for this feature, or is it just a
> matter of configuration or even just the right (maybe outdated?) GMF
> version?
>
> Kind regards,
> Tobias
Re: Copy-Paste [message #5771 is a reply to message #5753] Thu, 15 January 2009 09:08 Go to previous messageGo to next message
Eclipse UserFriend
Originally posted by: tobk42.gmx.de

Hello Antoine,

I found the files to look at and for now just copied them into my
project (of course with adaptions to some of the methods where it get's
STP-BPMN dependent). Right now I'm having the problem that while the
graphical element is copied, the semantic element is not, and instead a
reference to the root element is used as the semantic element. I'll
investigate that problem further and keep you informed. Of course, if
you remmber having had that problem yourself and what's the solution I
would be glad if you could tell me.

Regardig the latter part of my original question: Do you know about any
restrictions concerning the version of GMF (it was generated with) or
important configuration settings in the genmodel, gmfgen, or plugin.xml?

Best,
Tobias



Antoine Toulme schrieb:
> Each GMF based editor needs some work to make copy/paste work like it
> should be. The problem is that there is more than one way to copy stuff,
> do you want to copy the view, the semantic element, where do you paste,
> how do you deal with connected elements, etc.
>
> So you need to do a lot of little tweaks.
>
> Look for BpmnClipboardSupport for example.
>
> Thanks,
>
> Antoine
>
> Tobias wrote:
>> Hello,
>>
>> I noticed that in the STP-BPMN editor copy-paste works just fine, which
>> ist not as naturally for a GMF based editor. Could you please point me
>> to the part(s) of the code responsible for this feature, or is it just a
>> matter of configuration or even just the right (maybe outdated?) GMF
>> version?
>>
>> Kind regards,
>> Tobias
>
Re: Copy-Paste [message #5789 is a reply to message #5771] Thu, 15 January 2009 14:14 Go to previous messageGo to next message
Eclipse UserFriend
Originally posted by: atoulme.intalio.com

Tobias wrote:
> Hello Antoine,
>
> I found the files to look at and for now just copied them into my
> project (of course with adaptions to some of the methods where it get's
> STP-BPMN dependent). Right now I'm having the problem that while the
> graphical element is copied, the semantic element is not, and instead a
> reference to the root element is used as the semantic element. I'll
> investigate that problem further and keep you informed. Of course, if
> you remmber having had that problem yourself and what's the solution I
> would be glad if you could tell me.
Yeah, that's the default GMF behavior. You have to define what is
copied. So you will need to override isCopyAlways and add those bytes:

if (eReference.equals(NotationPackage.eINSTANCE
.getView_Element())) {
return true;
}

There might be more to do, but I think that's it.
>
> Regardig the latter part of my original question: Do you know about any
> restrictions concerning the version of GMF (it was generated with) or
> important configuration settings in the genmodel, gmfgen, or plugin.xml?

No, no idea about that.
>
> Best,
> Tobias
>
>
>
> Antoine Toulme schrieb:
>> Each GMF based editor needs some work to make copy/paste work like it
>> should be. The problem is that there is more than one way to copy
>> stuff, do you want to copy the view, the semantic element, where do
>> you paste, how do you deal with connected elements, etc.
>>
>> So you need to do a lot of little tweaks.
>>
>> Look for BpmnClipboardSupport for example.
>>
>> Thanks,
>>
>> Antoine
>>
>> Tobias wrote:
>>> Hello,
>>>
>>> I noticed that in the STP-BPMN editor copy-paste works just fine, which
>>> ist not as naturally for a GMF based editor. Could you please point me
>>> to the part(s) of the code responsible for this feature, or is it just a
>>> matter of configuration or even just the right (maybe outdated?) GMF
>>> version?
>>>
>>> Kind regards,
>>> Tobias
>>
Re: Copy-Paste [message #5808 is a reply to message #5789] Thu, 15 January 2009 14:40 Go to previous messageGo to next message
Eclipse UserFriend
Originally posted by: tobk42.gmx.de

Hello Antoine,

first, thank you very much for your help. I've tried all day now, but
can't get it to work. Basically I've tried three approaches:
1) Copy your implementation and replace/outcomment everything that does
not fit my domain model (none of this should be a problem)
2) Use the DefaultClipboardSupport
3) Derive a new class from AbstractClipboardSupport (the non-abstract
one) and add the lines you quoted below (I already noticed them in your
implementation)

With the following results:
1) the graphical element is copied, but the node's element is null when
entering the paste-part and is later set to a reference to the diagram
root object.
2) the behaviour is quite similar, with the difference that instead of
the diagram root, the semantic element of the original node is
referenced by the new node.
3) I get a nullpointer exception right after the third call of
shouldOverrideChildPasteOperation (here, the childEObject is null).

One thing I noticed: When copying an atomic node (my only testcase so
far) in the STP editor the method shouldOverrideChildPasteOperation is
called thrice: for the annotation, the node, and the node's element. In
my editor, in case 1) and 2) the method is called only twice, for the
annotation and the node (with node.element==null) and thrice for
approach 3) for the annotation, the node (element being null again) and
null (the element, as it seems), yielding the null pointer exception. So
the main problem seems to the that the semantic element's copy get's
lost (or is not created at all) somewhen between copy (when it is
included in the list of elements to copy) and paste.

I find it really hard to debug this part. Do you know of any good (web)
resource providing good documentation on this issue? I did not found any
so far.

Best regards,
Tobias



Antoine Toulme schrieb:
> Tobias wrote:
>> Hello Antoine,
>>
>> I found the files to look at and for now just copied them into my
>> project (of course with adaptions to some of the methods where it get's
>> STP-BPMN dependent). Right now I'm having the problem that while the
>> graphical element is copied, the semantic element is not, and instead a
>> reference to the root element is used as the semantic element. I'll
>> investigate that problem further and keep you informed. Of course, if
>> you remmber having had that problem yourself and what's the solution I
>> would be glad if you could tell me.
> Yeah, that's the default GMF behavior. You have to define what is
> copied. So you will need to override isCopyAlways and add those bytes:
>
> if (eReference.equals(NotationPackage.eINSTANCE
> .getView_Element())) {
> return true;
> }
>
> There might be more to do, but I think that's it.
>>
>> Regardig the latter part of my original question: Do you know about any
>> restrictions concerning the version of GMF (it was generated with) or
>> important configuration settings in the genmodel, gmfgen, or plugin.xml?
>
> No, no idea about that.
>>
>> Best,
>> Tobias
>>
>>
>>
>> Antoine Toulme schrieb:
>>> Each GMF based editor needs some work to make copy/paste work like it
>>> should be. The problem is that there is more than one way to copy
>>> stuff, do you want to copy the view, the semantic element, where do
>>> you paste, how do you deal with connected elements, etc.
>>>
>>> So you need to do a lot of little tweaks.
>>>
>>> Look for BpmnClipboardSupport for example.
>>>
>>> Thanks,
>>>
>>> Antoine
>>>
>>> Tobias wrote:
>>>> Hello,
>>>>
>>>> I noticed that in the STP-BPMN editor copy-paste works just fine, which
>>>> ist not as naturally for a GMF based editor. Could you please point me
>>>> to the part(s) of the code responsible for this feature, or is it
>>>> just a
>>>> matter of configuration or even just the right (maybe outdated?) GMF
>>>> version?
>>>>
>>>> Kind regards,
>>>> Tobias
>>>
>
Re: Copy-Paste [message #5827 is a reply to message #5808] Thu, 15 January 2009 16:21 Go to previous messageGo to next message
Eclipse UserFriend
Originally posted by: tobk42.gmx.de

Here's an update:

I've taken my local copy of the the STP-BPMN editor and stripped it of
roughly 95% of the clipboard support code, until all that was left were
the three methods below [1], and it still worked -- the node's element
is not null when entering shouldOverrideChildPasteOperation.

I noticed that in your domain model you use EModelElement as the super
class instead of just EObject, and all your metamodel elemets have an
annotation. Might this be the cause it works for you but not for me?

Regards, and again many thanks for your help.
Tobias

[1]
boolean isCopyAlways(...) {
if (eReference.equals(NotationPackage.eINSTANCE.getView_Element ())) {
return true;
}
return super.isCopyAlways(context, eReference, value);
}

boolean shouldOverrideChildPasteOperation(...) {
return childEObject.eClass().getEPackage()
== NotationPackage.eINSTANCE;
}

OPCO getOverrideChildPasteOperation(...) {
EObject eObject = overriddenChildPasteOperation.getEObject();
if (eObject instanceof Node) {
return new BpmnPositionalGeneralViewPasteOperation(
opco,((Node) eObject).getElement() != null);
}
return null;
}





Tobias schrieb:
> Hello Antoine,
>
> first, thank you very much for your help. I've tried all day now, but
> can't get it to work. Basically I've tried three approaches:
> 1) Copy your implementation and replace/outcomment everything that does
> not fit my domain model (none of this should be a problem)
> 2) Use the DefaultClipboardSupport
> 3) Derive a new class from AbstractClipboardSupport (the non-abstract
> one) and add the lines you quoted below (I already noticed them in your
> implementation)
>
> With the following results:
> 1) the graphical element is copied, but the node's element is null when
> entering the paste-part and is later set to a reference to the diagram
> root object.
> 2) the behaviour is quite similar, with the difference that instead of
> the diagram root, the semantic element of the original node is
> referenced by the new node.
> 3) I get a nullpointer exception right after the third call of
> shouldOverrideChildPasteOperation (here, the childEObject is null).
>
> One thing I noticed: When copying an atomic node (my only testcase so
> far) in the STP editor the method shouldOverrideChildPasteOperation is
> called thrice: for the annotation, the node, and the node's element. In
> my editor, in case 1) and 2) the method is called only twice, for the
> annotation and the node (with node.element==null) and thrice for
> approach 3) for the annotation, the node (element being null again) and
> null (the element, as it seems), yielding the null pointer exception. So
> the main problem seems to the that the semantic element's copy get's
> lost (or is not created at all) somewhen between copy (when it is
> included in the list of elements to copy) and paste.
>
> I find it really hard to debug this part. Do you know of any good (web)
> resource providing good documentation on this issue? I did not found any
> so far.
>
> Best regards,
> Tobias
>
>
>
> Antoine Toulme schrieb:
>> Tobias wrote:
>>> Hello Antoine,
>>>
>>> I found the files to look at and for now just copied them into my
>>> project (of course with adaptions to some of the methods where it get's
>>> STP-BPMN dependent). Right now I'm having the problem that while the
>>> graphical element is copied, the semantic element is not, and instead a
>>> reference to the root element is used as the semantic element. I'll
>>> investigate that problem further and keep you informed. Of course, if
>>> you remmber having had that problem yourself and what's the solution I
>>> would be glad if you could tell me.
>> Yeah, that's the default GMF behavior. You have to define what is
>> copied. So you will need to override isCopyAlways and add those bytes:
>>
>> if (eReference.equals(NotationPackage.eINSTANCE
>> .getView_Element())) {
>> return true;
>> }
>>
>> There might be more to do, but I think that's it.
>>>
>>> Regardig the latter part of my original question: Do you know about any
>>> restrictions concerning the version of GMF (it was generated with) or
>>> important configuration settings in the genmodel, gmfgen, or plugin.xml?
>>
>> No, no idea about that.
>>>
>>> Best,
>>> Tobias
>>>
>>>
>>>
>>> Antoine Toulme schrieb:
>>>> Each GMF based editor needs some work to make copy/paste work like it
>>>> should be. The problem is that there is more than one way to copy
>>>> stuff, do you want to copy the view, the semantic element, where do
>>>> you paste, how do you deal with connected elements, etc.
>>>>
>>>> So you need to do a lot of little tweaks.
>>>>
>>>> Look for BpmnClipboardSupport for example.
>>>>
>>>> Thanks,
>>>>
>>>> Antoine
>>>>
>>>> Tobias wrote:
>>>>> Hello,
>>>>>
>>>>> I noticed that in the STP-BPMN editor copy-paste works just fine,
>>>>> which
>>>>> ist not as naturally for a GMF based editor. Could you please point me
>>>>> to the part(s) of the code responsible for this feature, or is it
>>>>> just a
>>>>> matter of configuration or even just the right (maybe outdated?) GMF
>>>>> version?
>>>>>
>>>>> Kind regards,
>>>>> Tobias
>>>>
>>
Re: Copy-Paste [message #5844 is a reply to message #5827] Thu, 15 January 2009 16:22 Go to previous messageGo to next message
Eclipse UserFriend
Originally posted by: tobk42.gmx.de

Sorry, I forgot to mention: all the remaining methods are inherited from
org.eclipse.gmf.runtime.emf.clipboard.core.AbstractClipboard Support

Tobias



Tobias schrieb:
> Here's an update:
>
> I've taken my local copy of the the STP-BPMN editor and stripped it of
> roughly 95% of the clipboard support code, until all that was left were
> the three methods below [1], and it still worked -- the node's element
> is not null when entering shouldOverrideChildPasteOperation.
>
> I noticed that in your domain model you use EModelElement as the super
> class instead of just EObject, and all your metamodel elemets have an
> annotation. Might this be the cause it works for you but not for me?
>
> Regards, and again many thanks for your help.
> Tobias
>
> [1]
> boolean isCopyAlways(...) {
> if (eReference.equals(NotationPackage.eINSTANCE.getView_Element ())) {
> return true;
> }
> return super.isCopyAlways(context, eReference, value);
> }
>
> boolean shouldOverrideChildPasteOperation(...) {
> return childEObject.eClass().getEPackage()
> == NotationPackage.eINSTANCE;
> }
>
> OPCO getOverrideChildPasteOperation(...) {
> EObject eObject = overriddenChildPasteOperation.getEObject();
> if (eObject instanceof Node) {
> return new BpmnPositionalGeneralViewPasteOperation(
> opco,((Node) eObject).getElement() != null);
> }
> return null;
> }
>
>
>
>
>
> Tobias schrieb:
>> Hello Antoine,
>>
>> first, thank you very much for your help. I've tried all day now, but
>> can't get it to work. Basically I've tried three approaches:
>> 1) Copy your implementation and replace/outcomment everything that
>> does not fit my domain model (none of this should be a problem)
>> 2) Use the DefaultClipboardSupport
>> 3) Derive a new class from AbstractClipboardSupport (the non-abstract
>> one) and add the lines you quoted below (I already noticed them in
>> your implementation)
>>
>> With the following results:
>> 1) the graphical element is copied, but the node's element is null
>> when entering the paste-part and is later set to a reference to the
>> diagram root object.
>> 2) the behaviour is quite similar, with the difference that instead of
>> the diagram root, the semantic element of the original node is
>> referenced by the new node.
>> 3) I get a nullpointer exception right after the third call of
>> shouldOverrideChildPasteOperation (here, the childEObject is null).
>>
>> One thing I noticed: When copying an atomic node (my only testcase so
>> far) in the STP editor the method shouldOverrideChildPasteOperation is
>> called thrice: for the annotation, the node, and the node's element.
>> In my editor, in case 1) and 2) the method is called only twice, for
>> the annotation and the node (with node.element==null) and thrice for
>> approach 3) for the annotation, the node (element being null again)
>> and null (the element, as it seems), yielding the null pointer
>> exception. So the main problem seems to the that the semantic
>> element's copy get's lost (or is not created at all) somewhen between
>> copy (when it is included in the list of elements to copy) and paste.
>>
>> I find it really hard to debug this part. Do you know of any good
>> (web) resource providing good documentation on this issue? I did not
>> found any so far.
>>
>> Best regards,
>> Tobias
>>
>>
>>
>> Antoine Toulme schrieb:
>>> Tobias wrote:
>>>> Hello Antoine,
>>>>
>>>> I found the files to look at and for now just copied them into my
>>>> project (of course with adaptions to some of the methods where it get's
>>>> STP-BPMN dependent). Right now I'm having the problem that while the
>>>> graphical element is copied, the semantic element is not, and instead a
>>>> reference to the root element is used as the semantic element. I'll
>>>> investigate that problem further and keep you informed. Of course, if
>>>> you remmber having had that problem yourself and what's the solution I
>>>> would be glad if you could tell me.
>>> Yeah, that's the default GMF behavior. You have to define what is
>>> copied. So you will need to override isCopyAlways and add those bytes:
>>>
>>> if (eReference.equals(NotationPackage.eINSTANCE
>>> .getView_Element())) {
>>> return true;
>>> }
>>>
>>> There might be more to do, but I think that's it.
>>>>
>>>> Regardig the latter part of my original question: Do you know about any
>>>> restrictions concerning the version of GMF (it was generated with) or
>>>> important configuration settings in the genmodel, gmfgen, or
>>>> plugin.xml?
>>>
>>> No, no idea about that.
>>>>
>>>> Best,
>>>> Tobias
>>>>
>>>>
>>>>
>>>> Antoine Toulme schrieb:
>>>>> Each GMF based editor needs some work to make copy/paste work like it
>>>>> should be. The problem is that there is more than one way to copy
>>>>> stuff, do you want to copy the view, the semantic element, where do
>>>>> you paste, how do you deal with connected elements, etc.
>>>>>
>>>>> So you need to do a lot of little tweaks.
>>>>>
>>>>> Look for BpmnClipboardSupport for example.
>>>>>
>>>>> Thanks,
>>>>>
>>>>> Antoine
>>>>>
>>>>> Tobias wrote:
>>>>>> Hello,
>>>>>>
>>>>>> I noticed that in the STP-BPMN editor copy-paste works just fine,
>>>>>> which
>>>>>> ist not as naturally for a GMF based editor. Could you please
>>>>>> point me
>>>>>> to the part(s) of the code responsible for this feature, or is it
>>>>>> just a
>>>>>> matter of configuration or even just the right (maybe outdated?) GMF
>>>>>> version?
>>>>>>
>>>>>> Kind regards,
>>>>>> Tobias
>>>>>
>>>
Re: Copy-Paste [message #5862 is a reply to message #5844] Thu, 15 January 2009 17:04 Go to previous message
Eclipse UserFriend
Originally posted by: atoulme.intalio.com

Yes, since we use EModelElements everywhere, we take care of
annotations. You can remove that code safely. If that doesn't work, not
sure why it fails.

What you might want to do is to restart Eclipse every time you make
modifications, as this stuff is more or less static. So it doesn't get
updated if you edit code at debug time. That's more or less what I
remember of the experience, that was indeed once of the most painful I
ever went through.

The code in itself is a bit too obfuscated, but hey, that's necessary
given the complexity of copy/paste anyway.

Some people on the GMF newsgroup might be of better help than me. We
generated our code long time ago, and maybe there is now an option to do
the copy/paste in a nicer way.

Thanks,

Antoine

Tobias wrote:
> Sorry, I forgot to mention: all the remaining methods are inherited from
> org.eclipse.gmf.runtime.emf.clipboard.core.AbstractClipboard Support
>
> Tobias
>
>
>
> Tobias schrieb:
>> Here's an update:
>>
>> I've taken my local copy of the the STP-BPMN editor and stripped it of
>> roughly 95% of the clipboard support code, until all that was left
>> were the three methods below [1], and it still worked -- the node's
>> element is not null when entering shouldOverrideChildPasteOperation.
>>
>> I noticed that in your domain model you use EModelElement as the super
>> class instead of just EObject, and all your metamodel elemets have an
>> annotation. Might this be the cause it works for you but not for me?
>>
>> Regards, and again many thanks for your help.
>> Tobias
>>
>> [1]
>> boolean isCopyAlways(...) {
>> if (eReference.equals(NotationPackage.eINSTANCE.getView_Element ())) {
>> return true;
>> }
>> return super.isCopyAlways(context, eReference, value);
>> }
>>
>> boolean shouldOverrideChildPasteOperation(...) {
>> return childEObject.eClass().getEPackage()
>> == NotationPackage.eINSTANCE;
>> }
>>
>> OPCO getOverrideChildPasteOperation(...) {
>> EObject eObject = overriddenChildPasteOperation.getEObject();
>> if (eObject instanceof Node) {
>> return new BpmnPositionalGeneralViewPasteOperation(
>> opco,((Node) eObject).getElement() != null);
>> }
>> return null;
>> }
>>
>>
>>
>>
>>
>> Tobias schrieb:
>>> Hello Antoine,
>>>
>>> first, thank you very much for your help. I've tried all day now, but
>>> can't get it to work. Basically I've tried three approaches:
>>> 1) Copy your implementation and replace/outcomment everything that
>>> does not fit my domain model (none of this should be a problem)
>>> 2) Use the DefaultClipboardSupport
>>> 3) Derive a new class from AbstractClipboardSupport (the non-abstract
>>> one) and add the lines you quoted below (I already noticed them in
>>> your implementation)
>>>
>>> With the following results:
>>> 1) the graphical element is copied, but the node's element is null
>>> when entering the paste-part and is later set to a reference to the
>>> diagram root object.
>>> 2) the behaviour is quite similar, with the difference that instead
>>> of the diagram root, the semantic element of the original node is
>>> referenced by the new node.
>>> 3) I get a nullpointer exception right after the third call of
>>> shouldOverrideChildPasteOperation (here, the childEObject is null).
>>>
>>> One thing I noticed: When copying an atomic node (my only testcase so
>>> far) in the STP editor the method shouldOverrideChildPasteOperation
>>> is called thrice: for the annotation, the node, and the node's
>>> element. In my editor, in case 1) and 2) the method is called only
>>> twice, for the annotation and the node (with node.element==null) and
>>> thrice for approach 3) for the annotation, the node (element being
>>> null again) and null (the element, as it seems), yielding the null
>>> pointer exception. So the main problem seems to the that the semantic
>>> element's copy get's lost (or is not created at all) somewhen between
>>> copy (when it is included in the list of elements to copy) and paste.
>>>
>>> I find it really hard to debug this part. Do you know of any good
>>> (web) resource providing good documentation on this issue? I did not
>>> found any so far.
>>>
>>> Best regards,
>>> Tobias
>>>
>>>
>>>
>>> Antoine Toulme schrieb:
>>>> Tobias wrote:
>>>>> Hello Antoine,
>>>>>
>>>>> I found the files to look at and for now just copied them into my
>>>>> project (of course with adaptions to some of the methods where it
>>>>> get's
>>>>> STP-BPMN dependent). Right now I'm having the problem that while the
>>>>> graphical element is copied, the semantic element is not, and
>>>>> instead a
>>>>> reference to the root element is used as the semantic element. I'll
>>>>> investigate that problem further and keep you informed. Of course, if
>>>>> you remmber having had that problem yourself and what's the solution I
>>>>> would be glad if you could tell me.
>>>> Yeah, that's the default GMF behavior. You have to define what is
>>>> copied. So you will need to override isCopyAlways and add those bytes:
>>>>
>>>> if (eReference.equals(NotationPackage.eINSTANCE
>>>> .getView_Element())) {
>>>> return true;
>>>> }
>>>>
>>>> There might be more to do, but I think that's it.
>>>>>
>>>>> Regardig the latter part of my original question: Do you know about
>>>>> any
>>>>> restrictions concerning the version of GMF (it was generated with) or
>>>>> important configuration settings in the genmodel, gmfgen, or
>>>>> plugin.xml?
>>>>
>>>> No, no idea about that.
>>>>>
>>>>> Best,
>>>>> Tobias
>>>>>
>>>>>
>>>>>
>>>>> Antoine Toulme schrieb:
>>>>>> Each GMF based editor needs some work to make copy/paste work like it
>>>>>> should be. The problem is that there is more than one way to copy
>>>>>> stuff, do you want to copy the view, the semantic element, where do
>>>>>> you paste, how do you deal with connected elements, etc.
>>>>>>
>>>>>> So you need to do a lot of little tweaks.
>>>>>>
>>>>>> Look for BpmnClipboardSupport for example.
>>>>>>
>>>>>> Thanks,
>>>>>>
>>>>>> Antoine
>>>>>>
>>>>>> Tobias wrote:
>>>>>>> Hello,
>>>>>>>
>>>>>>> I noticed that in the STP-BPMN editor copy-paste works just fine,
>>>>>>> which
>>>>>>> ist not as naturally for a GMF based editor. Could you please
>>>>>>> point me
>>>>>>> to the part(s) of the code responsible for this feature, or is it
>>>>>>> just a
>>>>>>> matter of configuration or even just the right (maybe outdated?) GMF
>>>>>>> version?
>>>>>>>
>>>>>>> Kind regards,
>>>>>>> Tobias
>>>>>>
>>>>
Previous Topic:Error in EclipseCon2008 Tutorial
Next Topic:BPMN Modeler Webinar - Feb. 12
Goto Forum:
  


Current Time: Tue Mar 19 02:11:51 GMT 2024

Powered by FUDForum. Page generated in 0.03561 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software

Back to the top