#4651 closed defect (fixed)
Parameter dialog show extraneous "=" with parameters of Record types
Reported by: | Pierre Haessig <pierre.haessig@…> | Owned by: | adeas31 |
---|---|---|---|
Priority: | normal | Milestone: | 1.13.0 |
Component: | OMEdit | Version: | v1.12.0 |
Keywords: | Cc: |
Description
When editing the parameters of a Modelica component which includes a parameter which type is a Record, the OMEdit dialog shows an extraneous "=" sign after reopening the dialog.
Step to reproduce:
- open the attached RecordParamBug.mo package file
- open the testComponent model which contains one Component component1.
- edit (with OMEdit dialog) component1's parameter sx to some value. Eg. sx=sb (a constant defined in the package). Close the dialog.
- reopen the param dialog. sx parameter box now shows "= sb" (extraneous "=").
- If revalidating the dialog, an error is raised.
setComponentModifierValue(DotParamBug.testComponent, component1.sx, $Code(== sb))
Notice that the error at step 5 is sometimes not raise if the text field in left unchanged.
Attachments (1)
Change History (6)
Changed 7 years ago by Pierre Haessig <pierre.haessig@…>
comment:1 Changed 7 years ago by janK
A very good ticket! I had this error so often when selecting records...
I observed that the additional "=" appears when a record is chosen which is parsed AFTER the parameter declaration. Consider the following counterexample: If an element of the type of the record is added as an (invisible) element to the icon view, the additional "=" is not present. Hope this helps a bit to find the bug :)
comment:2 Changed 7 years ago by janK
I think ticket #4697 is related. Could someone please check?
comment:3 Changed 7 years ago by adeas31
- Milestone changed from Future to 1.13.0
- Resolution set to fixed
- Status changed from new to closed
Fixed in 4e15c16/OMEdit.
comment:4 Changed 7 years ago by janK
Nice! Thank you so much :)
comment:5 Changed 7 years ago by Pierre Haessig <pierre.haessig@…>
Thanks a lot! These days I'm on the beta channel rather than nightly, so I can't confirm the fix yet but I guess it's ok.
package to reproduce issue #4651