Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 360974

Summary: [Activity Diagram] Set the value of an argument in a CallOperationAction should be possible
Product: [Modeling] Papyrus Reporter: David Rabely <david.rabely>
Component: DiagramAssignee: Project Inbox <mdt-papyrus-inbox>
Status: RESOLVED FIXED QA Contact:
Severity: major    
Priority: P3 CC: alexandre.cortier, arnaud.cuccuru, cletavernier, raphael.faudou
Version: 0.10.0Flags: cletavernier: documentation-
Target Milestone: ---   
Hardware: All   
OS: All   
Whiteboard:
Attachments:
Description Flags
Steps to Type the InstanceValue of the operation's parameter
none
Result of the steps to type an operation's parameter none

Description David Rabely CLA 2011-10-14 10:09:59 EDT 
Build Identifier: M20110909-1335

In a  CallOperationAction, it is not possible to set the value of an argument. So the solution should be to create an Instance Value and to change its type and its instancevalue. The editor do nothing, thus trying to change the type of the InstanceValuePin will display several "unauthorized" messages. The aim is to set the default InputPin with a ValuePin without creating a parameter.

Reproducible: Always

Steps to Reproduce:
1.Right click on an argument of a callOperationAction in the model Explorer view
2.Create Child > select "InstanceValue"
3.Change the instance and the type of the InstanceValue
Comment 1 Camille Letavernier CLA 2011-10-18 04:47:08 EDT 
> In a  CallOperationAction, it is not possible to set the value of an argument.

What kind of argument do you use ? If you select an InputPin, there is no value. However, if you select a ValuePin, you can set a value.

> So the solution should be to create an Instance Value and to change its type and its instancevalue.

When you create an InstanceValue in an InputPin, you're actually creating an "upperValue" (Which should be an UnlimitedLiteralInteger). The problem is that the ModelExplorer is tightly related to the Ecore implementation of UML, instead of UML itself. It really doesn't make sense to create an InstanceValue in an InputPin.

Maybe this will be less confusing when this task will be done :

Bug 358584: [model explorer] improve the create child
Comment 2 Camille Letavernier CLA 2011-10-18 04:58:18 EDT 
Hmm actually the arguments are pre-instantiated with arguments corresponding to the operation's parameters.

The problem is that they are instantiated with InputPins, whereas the user should be able to choose from either an InputPin, ActionInputPin or ValuePin for each parameter.
Comment 3 David Rabely CLA 2011-11-02 09:59:04 EDT 
Created attachment 206331 [details]
Steps to Type the InstanceValue of the operation's parameter

Steps to Type the InstanceValue of the operation's parameter
Comment 4 David Rabely CLA 2011-11-02 10:03:08 EDT 
Created attachment 206332 [details]
Result of the steps to type an operation's parameter

So I use as argument the operation's parameter and I try to associate an InstanceValue but it is not authorized. (See attachment files)
Comment 5 Alexandre Cortier CLA 2011-11-07 12:01:37 EST 
I agree with you : it is not possible to change the nature of  input pins of CallOperationActions due to the synchronization of input pins and operation parameters.

So, it seems that  several modifications have to be take into account to handle this bug : 
1/ Modification of the synchronization action : ValuePins sould not be transformed into InputPins during the execution of the synchronization action
2/ Some actions in the model explorer should allow to transform an InputPin in a ValuePin (or in ActionInputPin)

Best regards,




(In reply to comment #2)
> Hmm actually the arguments are pre-instantiated with arguments corresponding to
> the operation's parameters.
> 
> The problem is that they are instantiated with InputPins, whereas the user
> should be able to choose from either an InputPin, ActionInputPin or ValuePin
> for each parameter.
Comment 6 Arnaud Cuccuru CLA 2015-10-30 07:14:31 EDT 
Tested on Mars 1.1.3.
As far as I know, the automatic synchronization of pins have been deactivated.
I propose to close the bug.
Comment 7 Camille Letavernier CLA 2015-10-30 07:38:41 EDT 
> As far as I know, the automatic synchronization of pins have been deactivated.

Indeed

> I propose to close the bug.

Done