Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

clarify meaning of nested hideResult annotation #3457

Open
gkurzbach opened this issue Dec 11, 2023 · 6 comments
Open

clarify meaning of nested hideResult annotation #3457

gkurzbach opened this issue Dec 11, 2023 · 6 comments
Milestone

Comments

@gkurzbach
Copy link
Collaborator

gkurzbach commented Dec 11, 2023

It is possible to set the hideResult annotation on composite components, e.g. complete submodels or data sets. It then has an effect on the contained variables.
But then it is unclear who wins if there is a hideResult annotation for both the composite component and an inner variable and they contradict each other. See following (incomplete) truth table

hideResult on

Component Variable Result
true none true
false none false
none true true
none false false
true false ??
false true ??

Please clarify.

@HansOlsson
Copy link
Collaborator

Dymola gives precedence for the lowest level (variable), but I'm not sure that is ideal.

For Evaluate the highest level is currently given precedence in the specification - but Dymola as default only give precedence for Evaluate=true on the highest level (so basically Evaluate=true if set for least one of them) due to customer models.

@gkurzbach
Copy link
Collaborator Author

An example: 'hideResult=true' is used in one of our customer's libraries to reduce the number of results on a composit component. He does not want any results from the sub-component.
In this case, it seems to make sense for annotations on higher level (composite) to overwrite lower level annotations.

@HansOlsson
Copy link
Collaborator

An example: 'hideResult=true' is used in one of our customer's libraries to reduce the number of results on a composit component. He does not want any results from the sub-component. In this case, it seems to make sense for annotations on higher level (composite) to overwrite lower level annotations.

Another interpretation is that it would be an or of the different ones. It would work for that case. The question is whether we have the case where someone has a component where they need hideResult=false to unhide a component - including ones having hideResult=true?

@gkurzbach
Copy link
Collaborator Author

Another interpretation is that it would be an or of the different ones. It would work for that case. The question is whether we have the case where someone has a component where they need hideResult=false to unhide a component - including ones having hideResult=true?

Composite models are usually designed inside out. First inner components are defined and the they are put in an enclosing model.
So the common case is to override inner settings from outside. Both use cases seem to be valid, but a modeler is not able to specify one of the two cases, depending on the defined rules.

@HansOlsson HansOlsson added this to the 2024-1 milestone Feb 15, 2024
@HansOlsson
Copy link
Collaborator

HansOlsson commented Feb 20, 2024

Language group:

  • Precedence for hiding in case of conflicts (tools can always decide to store/show more).

Also consider using "protected".
Think more about it (including animation and similar cases where you want to include it - but can see as deliberate action).

@sbaetzing
Copy link

Some hints from the perspective of a model developer.
Not in all cases it possible to use "protected" since replaceable class declarations wont appear inside the parameter dialog. That is why we are going with hideResult instead.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants