OMEdit removes constants from package.order file

[Martin Sjölund]

OMEdit corrputs the parsing of libraries in some cases. For example, open Modelica_DeviceDrivers.Utilities (a package containing a constant, and other elements stored in separate files).

Edit the class (any legal edit), save the package. The package.order file now no longer contains RootDir (the constant in the package), which makes the directory structure invalid.

[Martin Sjölund]

Would be good to have this UI bug fixed in 1.11...

[Adeel Asghar]

If we return constants from getClassNames then we don't have this issue.
However, we might have other issues like handling constants in Libraries Browser but I can fix them.

[Martin Sjölund]

Well, it's not a class so getClassNames should not return it... I guess you need to get all constants in a separate call? Or something similar to getElementName?

[Adeel Asghar]

I think I can also use getComponents and then can filter out constants from it. As far as I understood from the specification we only need to consider constants.

Classes and constants that are stored in package.mo are also present in package.order but their relative order should be identical to the one in package.mo (this ensures that the relative order between classes and constants stored in different ways is preserved).

The only thing worries me a package.mo like this,

package Utilities
  model M end M;
  constant String constant1="";
  model N end N;
  constant String constant2="";
end Utilities;

Its difficult to generate a correct order if I get classes from one API and constants from the other API. That is why I said we should have constants as part of getClassNames. I think dymola is doing exactly like this. For example try opening the above package in Dymola, you will see constant1 and constant2 in the Package Browser.

[Martin Sjölund]

Then add a new API call or a new flag to getClassName(includeConstants=true), or a getElementNames, which returns all element names (which could then be filtered).

[Adeel Asghar]

Fixed in a475e18/OMCompiler and e824f37/OMEdit.

[Martin Sjölund]

You have milestone set to 1.11, but those commits are not part of 1.11

[Martin Sjölund]

Yes, I ported it to 1.11 today :)

[Adeel Asghar]

Yeah I saw that so I changed the milestone back to 1.11. Thanks.