This sounds like the unit elements are deleted and re-created every time the object is reloaded. This would match your observations: Always when changing an object parameter, its owner object is reloaded immediately. So, when selecting the object's own unit element, the object instance is reloaded and the parameter gets lost immediately. When connecting a unit element of another instance, it will only get lost when that other instance is reloaded, i.e. when reloading STD or when a parameter of that instance is changed.
Now the important question is why the unit elements get lost when reloading the object. This usually happens when the object developer tries to "override" the inherited unit variable with a different type by using the same refId used in the BaseRef object. Re-using refIds is generally not supported, though. When doing this, everything may look fine at first sight. But this is what happens while reloading the object:
OES reads through the BaseRef OOD, finds the variable in the project by refId and changes its type definition because it is different in the BaseRef. All elements are removed and replaced, so all references (e.g. the usage in the object parameters) are lost.
Next, OES reads through the specialized OOD, finds the same variable and changes its type definition again.
Afterwards, all the elements look correct as before, but their references are gone.
When replacing the unit FB and instance in a specialized object definition, you need to use your own unique refId (e.g. a new Guid). Also add a UseAs Unit tag. The inherited unit variable will be automatically replaced in this case. When using conditions to switch between multiple units, any inactive inherited unit may still be visible in the project, but it is grayed out and will not be exported.
By the way: We are planning to support overrides in OOD files in Control plus Studio 5.5.
... View more
