Community
Participate
Working Groups
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
> 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
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.
Created attachment 206331 [details] Steps to Type the InstanceValue of the operation's parameter Steps to Type the InstanceValue of the operation's parameter
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)
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.
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.
> As far as I know, the automatic synchronization of pins have been deactivated. Indeed > I propose to close the bug. Done
