You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
EllipseClosure closure =
if startAngle == 0 and endAngle == 360 then
EllipseClosure.Chord
else
EllipseClosure.Radial;
Since the startAngle and endAngle can't be referenced in an expression, there currently is no way to put the default behavior in the first argument of a DynamicSelect.
I suggest that the default is described using a dedicated enumerator, and that the behavior is described in the text instead:
EllipseClosure closure = EllipseClosure.Default;
The behavior of EllipseClosure.Default is defined as EllipseClosure.Radial unless when startAngle is 0 and endAngle is 360, when it is EllipseClosure.Chord instead.
I am not suggesting this because the use of DynamicSelect is extremely relevant for closure, but because this makes it impossible for GUIs to treat this attribute consistently with the other Ellipse attributes, and we have already lost too much time whining about this trivially fixable problem internally at Wolfram.
The text was updated successfully, but these errors were encountered:
henrikt-ma
changed the title
Impossible to use default ellipse closure with DynamicSelect
Impossible to use default Ellipse closure with DynamicSelect
Feb 5, 2025
It seems like an omission to not define the default for
Ellipse.closure
using a dedicated enumerator. From https://specification.modelica.org/master/annotations.html#ellipse:Since the
startAngle
andendAngle
can't be referenced in an expression, there currently is no way to put the default behavior in the first argument of aDynamicSelect
.I suggest that the default is described using a dedicated enumerator, and that the behavior is described in the text instead:
I am not suggesting this because the use of
DynamicSelect
is extremely relevant forclosure
, but because this makes it impossible for GUIs to treat this attribute consistently with the otherEllipse
attributes, and we have already lost too much time whining about this trivially fixable problem internally at Wolfram.The text was updated successfully, but these errors were encountered: