getComponentAnnotations should evaluate the parameters

[Adeel Asghar]

getComponentAnnotations should evaluate the parameters inside the annotations and return the correct annotations result.

For example,

loadModel(Modelica)
getComponentAnnotations(Modelica.Mechanics.MultiBody.World)

true
{{Placement(true,0.0,0.0,84.0,-16.0,116.0,16.0,0.0,0.0,0.0,-,-,-,-,0.0)},{},{Dialog(error)},{Dialog(error)},{},{},{},{Dialog(error)},{},{Dialog(error)},{},{Dialog(error)},{Dialog(error)},{Dialog(error)},{Dialog(error)},{Dialog(error)},{Dialog(error)},{Dialog(error)},{Dialog(error)},{Dialog(error)},{Dialog(error)},{Dialog(error)},{Dialog(error)},{Dialog("Defaults","Parameters",true,false,"",false)},{Dialog("Defaults","Parameters",true,false,"",false)},{Dialog("Defaults","Parameters",true,false,"",false)},{Dialog("Defaults","Parameters",true,false,"",false)},{Dialog("Defaults","Parameters",true,false,"",false)},{Dialog("Defaults","Parameters",true,false,"",false)},{Dialog("Defaults","Parameters",true,false,"",false)},{Dialog("Defaults","Parameters",true,false,"",false)},{Dialog("Defaults","Parameters",true,false,"",false)},{Dialog("Defaults","Parameters",true,false,"",false)},{Dialog("Defaults","Parameters",true,false,"",false)},{Dialog("Defaults","Parameters",true,false,"",false)},{Dialog("Defaults","Parameters",true,false,"",false)},{},{},{},{},{},{},{},{},{},{},{},{},{},{},{},{},{},{},{},{},{},{},{},{}}

[Francesco Casella]

This functionaly is require in order to get the correct results for the GUI in the case of models with conditional connectors, which is crucial in order to get a meaningful rendering of the MSL in OMEdit. It is also useful for the Enable annotation, which is often used in MSL to help the end user setting only those parameters that make sense to set. The lack of support for such functionality might lead to a very confusing appearance of many models in the MSL, whose interface was designed with such features in mind.

I would then recommend to fix it with high priority, as all the infrastructure in OMEdit is now ready to handle this correctly.

[Martin Sjölund]

Postponed until 1.9.1

[Martin Sjölund]

This ticket was not closed for 1.9.1, which has now been released. It was batch modified for milestone 1.9.2 (but maybe an empty milestone was more appropriate; feel free to change it).

[Martin Sjölund]

Milestone changed to 1.9.3 since 1.9.2 was released.

[Martin Sjölund]

Moved to new milestone 1.9.4

[Adeel Asghar]

The same behavior is experienced when the code contains some tool specific annotations. See #3655.

[Martin Sjölund]

Milestone pushed to 1.9.5

[Martin Sjölund]

Milestone renamed

[Martin Sjölund]

Ticket retargeted after milestone closed

[Martin Sjölund]

Milestone moved to 1.12.0 due to 1.11.0 already being released.

[Francesco Casella]

I guess it's finally time to address this.

@adrpo, can we have this in 1.13.0 together with replaceable support? Otherwise, please change the milestone to 2.0.0

[Francesco Casella]

Will implement this in 1.14.0, once the new-front-end-based API is stable.

[Francesco Casella]

See #2081, I guess it's basically the same issue

[Francesco Casella]

Releasing 1.14.0 which is stable and has many improvements w.r.t. 1.13.2.

This issue, previously marked as blocker for 1.14.0, is rescheduled to 1.15.0

[Francesco Casella]

Release 1.15.0 was scrapped, because replaceable support eventually turned out to be more easily implemented in 1.16.0. Hence, all 1.15.0 tickets are rescheduled to 1.16.0

[Francesco Casella]

Retargeted to 1.17.0 after 1.16.0 release

[Francesco Casella]

Rescheduled to 1.18.0

[Francesco Casella]

Ticket retargeted after milestone closed

[Francesco Casella]

1.18.0 blocker tickets moved to 1.19.0