Opened 6 years ago
Closed 6 years ago
#5380 closed defect (fixed)
Path to type definition in DAE.ElementSource not available
Reported by: | Karim.Abdelhak | Owned by: | perost |
---|---|---|---|
Priority: | critical | Milestone: | Future |
Component: | New Instantiation | Version: | |
Keywords: | Path, ElementSource | Cc: | adrpo |
Description
When calling ElementSource.getElementSourceTypes it always returns an empty list. The information for the property list<Absyn.Path> typeLst from DAE.ElementSource does not seem to be propagated through the NF and therefore not available in the Backend.
RTE updated their version of OMC and used this function to dump some information. In 1.9.4 it still worked.
Change History (3)
comment:1 follow-up: ↓ 2 Changed 6 years ago by perost
comment:2 in reply to: ↑ 1 Changed 6 years ago by Karim.Abdelhak
comment:3 Changed 6 years ago by Karim.Abdelhak
- Resolution set to fixed
- Status changed from new to closed
Possibly fixed in cbb67f0b, except that I'm not entirely sure what the expected behaviour is supposed to be. The comment in the code for typeLst says that it's "the classes where the type(s) of the element is defined", but what's actually added to the list seems to be the fully qualified names of the types of an element's parents in the instance tree. Anyway, the new frontend will at least add something to typeLst now, so let me know if it's what you were looking for or if we need to tweak it.
However, the old frontend only adds this information if either the -d=infoXmlOperations or the -d=visxml flag is given, so I did the same in the new frontend. Having it turned on by default is probably not a good idea, since it can be quite expensive, but if you wish to use some other flag we can of course change it (it's defined in NFConvertDAE.convertVariables if you wish to change it yourself).