We've had feedback from Sparx (in black) and responsed...
It seems to me that there are two commands here that have been designed to work in isolation. Firstly, there's the command to set the diagram to IDEF1X notation: this command hides all labels that conflict with the IDEF1X notation, not unreasonable behaviour for a self-contained command. Secondly, there is the command to set the diagram to UML notation: this doesn't change the show/hide status of any labels, again not unreasonable behaviour for a self-contained command. The problem is that the two commands weren't designed to round-trip: executing one command doesn't undo the other.
I'm OK with that, per se... My problem is with the notion that the Changeable: item conflicts with IDEF1X... I don't think it does. It's orthogonal to it. It isn't UML yet it is displayed in that notation regardless. I want the same for IDEF1X and IE. (This notion should be true for all such orthogonal properties that EA maintains)
I think the solution probably lies in the much requested feature to show or hide multiple connector labels (e.g. show all labels on a diagram/on multiply-selected connectors). I have no information on if or when that functionality might be added to EA.
That's part of it... However, I don't actually think it's a labelling problem per se...
PS you wrote " NOW... Here's the clincher... If you have defined a multiplicity for that end, you CANNOT reset the (end)Bottom Label." I don't understand this statement. Multiplicity and changeability share the same label, which is an inconvenience for display purposes, but I don't see any defective behaviour associated with that fact.
From a (or at least, this) user perspective, the defect is the inability to restore the bottom label. Conceding that (by default) the conversion from UML to IE (or IDEF1X) changes some things, the user should be warned that this will happen and should be allowed to customize the result. It's not up to EA to force that on me.
Now to the fact that multiplicity and changeability share the same label - that is, frankly, Sparx's problem not the user's. From a (or at least, this) user perspective, if we change notation (and by the way, the notation should be changeable on a per-edge basis), multiplicity should/should not be rendered into the label (depending on whether the multiplicity is rendered by glyph or not). Merely hiding the label is a hack (or even cruft)...
Paolo (and Darren)
