Omedit shows a component's icon but when checking does not find it

[massimo ceraolo]

Consider the enclosed package "OOInertia.mo"

Select in OMEdit the model OOInertia.DO.ThreeLosses

The component "propdriver1" is correctly displayed (no red-box).
However, when checking this model OMC cannot find it because of a path issue.

[Per Östlund]

The model is wrong. The structure of the package looks like this:

package OOInertia
  package Components
    model PropDriver
      ...
    end PropDriver;
  end Components;

  package DO
    package OOInertia
      ...
    package OOInertia;
  
    package ThreeLosses
      OOInertia.Components.PropDriver propdriver1;
      ...
    end ThreeLosses;
end OOInertia;

When the compiler looks up the class for propdriver1 it will find OOInertia inside DO first, which does not contain a Components package. The Modelica name lookup rules then says that you should stop looking, so the compiler gives an error message. You need to declare the class for propdriver1 as either .OOInertia.Components.PropDriver or Component.PropDriver.

[massimo ceraolo]

I suspected this.
What I meant with the ticket was that OM should behave consistently.

Either PropDriver should not be seen, not being visible according to the Modelica's rules, or It could be seen.

You've checked that that model must not be seen because of the Modelica visibility rules. In this case, this should also imply the red box in its place, when that model is open in graphical view.

[Per Östlund]

Ok, I loaded the file in Dymola, and see what you mean. OMEdit is unfortunately completely broken for me though, so either someone needs to fix #3525 or tell me what's going wrong with OMEdit (I'm guessing it's some API issue).

[Adeel Asghar]

I have created a small example of the same issue. The problem seems to be with getComponents API. The API should only return the qualified paths.

getComponents(P.DO.ThreeLosses)
{{P.Components.PropDriver,propdriver1,"", "public", false, false, false, false, "unspecified", "none", "unspecified",{}}}

[Per Östlund]

In 08f0eec getComponents now returns an empty typename for any component for which the type can't be found.

[massimo ceraolo]

The enclosed TestConnect.mo" shows the problem is still existing.

• Open TestConnect
• Select IdOnePwm the block "TestConnect.PwmPulser pmwPulser" is shown
• check: OM complains about TestConnect.PwmPulser not being in scope.

Either PwmPulser is in scope (and the model should check) or it is not (and the red box should be displayed)

[massimo ceraolo]

Note that this strange situation was created only acting graphically on OMEdit.

So, when this ticket is solved, I will try to single out which actions on OMEdit cause this type of code that, AFAIK, is invalid.
(I mean the IdOnePwm code in the context of the TestConnect package)

[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]

The milestone of this ticket has been reassigned to "Future".

If you think the issue is still valid and relevant for you, please select milestone 1.13.0 for back-end, code generation and run-time issues, or 2.0.0 for front-end issues.

If you are aware that the problem is no longer present, please select the milestone corresponding to the version of OMC you used to check that, and set the status to "worksforme".

In both cases, a short informative comment would be welcome.

[massimo ceraolo]

With OM 1.13.0-dev 215 the issue is not there anymore. I'm going to close this ticket.

[massimo ceraolo]

Pls check (and in case correct) the milestone. I don't see it in Italian and I don't know how to switch my trac GUI to English.

[Adrian Pop]

You just go to Preferences: https://trac.openmodelica.org/OpenModelica/prefs, tab Language.

[massimo ceraolo]

Ok I've changed to English.
But still don't know how to correctly close this ticket. The only thing I know is that two years ago the issue was there and with 1.13.0 Dev 215 it is not there anymore.
If I've closed it wrong I would gladly accept any correction.

[Francesco Casella]

The "Version" field refers to the version of the sofware you experienced the problem with.

The "Milestone" filed refers to the point in time the problem was solved, or found to be solved. Which in this case is 1.13.0, if I understand it correctly.