#2661 closed defect (fixed)
annotation(Dialog(enable = ...)) is not working correctly
Reported by: | Owned by: | Adeel Asghar | |
---|---|---|---|
Priority: | blocker | Milestone: | 1.21.0 |
Component: | OMEdit | Version: | trunk |
Keywords: | Cc: | Dietmar Winkler, Adrian Pop |
Description
I noticed the following issue in r20061 under Ubuntu 12.04, 32 bit.
I wanted to modify the parameter mu_rConst
in the diagram parameter mode of an instance of
Modelica.Magnetic.FluxTubes.Shapes.FixedShape.Cuboid
But I cannot change the parameter, even though nonLinearPermeability
is set to false
. I can certainly set the parameter textually, but it does not work in the diagram mode of OMEdit.
I attached an example to demonstrate the issue (right click on iron -> Paramerers -> mu_rConst cannot be modified).
Attachments (1)
Change History (29)
by , 11 years ago
Attachment: | Example.mo added |
---|
comment:1 by , 10 years ago
Milestone: | 1.9.1 → 1.9.2 |
---|
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).
comment:2 by , 10 years ago
Tested the attached example with r24056 under Ubuntu 14.04 and noticed that this issue still exists. I think the same applies to Windows 7, where I recently stumbled into a similar problem.
comment:3 by , 10 years ago
Milestone: | 1.9.2 → 1.9.3 |
---|
Milestone changed to 1.9.3 since 1.9.2 was released.
comment:4 by , 10 years ago
Some more details what else does not work with the enable
option.
parameter Boolean enableFoo annotation (Dialog(tab="Foo")); parameter Integer Bar annotation (Dialog(tab="Foo", group="Bar", enable=enableFoo));
Will place enableFoo
correctly in the "Foo" tab but Bar
will appear in the "General".
What I noticed is that the input can actually be enables/disabled as long as the value is hard coded in the modelica source. But OMedit will not react on any changes done to the Boolean in OMedit itself.
comment:6 by , 9 years ago
Small update. In my example above about the placement. Bar
is as of 1.9.4~dev.beta1
correctly placed in the "Foo" tab. But the original bug of not being able to enter any value into Bar
is still valid.
comment:9 by , 9 years ago
One of our customers came across this problem when trying to use
Modelica.Blocks.Sources.CombiTimeTable
in OpenModelica 1.9.6.
If you set tableOnFile=true
, you still cannot define tableName
or fileName
.
CombiTimeTable is a very frequently used block, therefore GUI support would be highly appreciated.
comment:10 by , 9 years ago
Status: | new → assigned |
---|
follow-up: 14 comment:11 by , 9 years ago
The problem here is that we evaluate the parameter once via getComponentAnnotations in the model and we don't do it again if is changed from OMEdit.
We need some sort of sequence setParameterValue, getComponentAnnotations again while the dialog is active. Adeel, could you try something like this?
comment:12 by , 8 years ago
Milestone: | 1.10.0 → 2.0.0 |
---|---|
Priority: | high → blocker |
comment:14 by , 8 years ago
Replying to adrpo:
The problem here is that we evaluate the parameter once via getComponentAnnotations in the model and we don't do it again if is changed from OMEdit.
We need some sort of sequence setParameterValue, getComponentAnnotations again while the dialog is active. Adeel, could you try something like this?
No, this will not work since the parameters are set as modifiers on the component instance. I need some sort of component instance from OMC.
comment:16 by , 7 years ago
Cc: | added |
---|
@adeas31, @adrpo is this going to be finally resolved with the new frontend-based API?
comment:17 by , 7 years ago
Cc: | added |
---|
comment:18 by , 6 years ago
Milestone: | 2.0.0 → 1.14.0 |
---|
I understand from @adrpo that this should be fairly easily implemented with the new front-end-based API, so I am retargeting this to 1.14.0
comment:20 by , 5 years ago
@adeas31, I understand this requires changes both to OMEdit and to the API. Are the former already done, and what is missing from the API?
comment:21 by , 5 years ago
Milestone: | 1.14.0 → 1.15.0 |
---|
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
comment:22 by , 4 years ago
Milestone: | 1.15.0 → 1.16.0 |
---|
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
comment:27 by , 2 years ago
Milestone: | 1.19.0 → 1.21.1 |
---|---|
Resolution: | → fixed |
Status: | assigned → closed |
Example demonstrates the issue