1. McGill CORE Avatar McGill CORE
  2. TouchCORE
  3. touchram
  4. Issues

Changing the return type to void does not remove return values from message view

Issue #409 resolved
Céline Bensoussan created an issue

After changing the return type of an operation to void, if the message view had a return value, it is not being deleted and there is no way to remove it.

Steps to reproduce:

  • Create a class
  • Create an operation to this class with a return type other than void
  • Create a message view and select a return value
  • Go back to the structural view and update the return type of the operation to void
  • Go to the message view, the return value is still there

Comments (31)

  3. Matthias Schoettle

    Not sure if it should automatically remove it. It might be better to have a constraint and allow to remove it, because the modeller might not be aware of this problem otherwise.

  4. Céline Bensoussan reporter

    I think it is alright to not remove it automatically but it should allow to remove it manually.

  6. Matthias Schoettle

    I just realized that the same applies to assignments on message calls as well. If a message is created to an operation that does return something, in the UI there will be shown the assignment view. However, if the operation that is called is changed to return void this assignment is invalid.

  7. Emmanuel Ng Cheng Hin

    I tried to force TouchCORE to update the messageViewView every time that the user switches to the message view screen (from my understanding this was not the case before). I am unsure whether it affects the performance, but it seems to fix this issue (the assignment is removed when the return type is changed to void, at least visually).

    (I modified the showMessageView method in the DisplayAspectScene class)

  8. Matthias Schoettle

    Usually, all the updates come in as notifications from the model that something has changed. That's why this is generally not required to force updating at some point. So I consider this more of a workaround/hack ;)

    The other issue is that this only removes it visually, however, in the model there is still (if it was set before) a reference in the message to a property (Message.assignTo).

    For example, a similar problem existed when adding/removing a parameter from an operation. Because messages have a ParameterValueMapping for each parameter. See methods createParameter/removeParameter in ClassController.

  9. Matthias Schoettle

    The other issue is that this only removes it visually, however, in the model there is still (if it was set before) a reference in the message to a property (Message.assignTo or Message.returns).

    For this it would be good to have test cases.

  28. Matthias Schoettle

    References #409: Removes removal of all other assignments to the same property.

    Only the "assignTo" of the affected message is removed. In addition, if it assigned to a temporary property that is not assigned anywhere else, the property is also removed.

    → <<cset 86a23da87ea0>>

  30. Matthias Schoettle

    References #409 & Bug fix: Fixes a bug in changeAssignTo and createTemporaryAssignment where temporary properties were always deleted.

    Now, the proper method from FragmentsController is used to determine whether temporary properties need to be removed.

    Removal of assignment now uses changeAssignTo to set the assignment to null.

    Adds additional test cases to handle the different cases.

    → <<cset 88ba4cff3c3d>>

  32. Log in to comment
Assignee
Type
bug
Priority
minor
Status
resolved
Component
Message View
Milestone
Introduction
Votes
0
Watchers
1
Jira: the preferred issue tracker for Bitbucket. Join the team!