Community
Participate
Working Groups
Papyrus shall provide Dialog box during the creation of an element . Creating an element triggers a choice between associating it to an existing element, creating new element or not specifying anything. For example: - when creating a Signal message a dialog box may be opened to propose to link or create an associated signal. This functionality must be optional and may be deactivated or activated by the preference. This functionality could be done for all diagrams. This requirement must be detailed by sub-requirement that list which elements must be configured by dialog box.
I am not sure that dialog is the best choice here. Sometimes it might be better to have a popup menu that is placed right next to the current position of the mouse. This requires the user to move the mouse a much shorter distance to make this kind of selection. We have some examples of this in Papyrus-RT where the creation of port or capsule part directly presents a popup menu with the choice of either create a new model element or select an existing for typing the port or capsule part. I think that it should be elaborated if a similar approach is best here as well.
Indeed, this should instead be implemented by a popup menu. By default, an operation is created when no operation exists, and if there are existing operations, a choice should be provided. The same applies to other message sorts.
(In reply to Mathilde Arnaud from comment #2) > By default, an operation is created when no operation exists, and if there > are existing operations, a choice should be provided. > The same applies to other message sorts. Regarding the aspect of creating an operation, and presenting existing operations/signals (based on receptions) to select from, I guess it must be considered all aspects of what actually is available to select, i.e. based on Generalization and InterfaceRealization for example, but also operations available via ports and the ports type, which in its turn also can have Generalization, InterfaceRealization, and also Usage, in which case the conjugation of the port also needs to be considered. See the discussion in Bug 366410 related to these aspects.
(In reply to Peter Cigehn from comment #3) > Regarding the aspect of creating an operation, and presenting existing > operations/signals (based on receptions) to select from, I guess it must be > considered all aspects of what actually is available to select, i.e. based > on Generalization and InterfaceRealization for example, but also operations > available via ports and the ports type, which in its turn also can have > Generalization, InterfaceRealization, and also Usage, in which case the > conjugation of the port also needs to be considered. See the discussion in > Bug 366410 related to these aspects. Good point, thanks for pointing it out.
