Developer Portal Community

    cancel
    Showing results for 
    Search instead for 
    Did you mean: 
    SOLVED

    Object parameters get lost (multiple units defined in ood)

    Object parameters get lost (multiple units defined in ood)

    MarvinW
    Long-established Member

    Hello,

    I found 2 behaviors in OES v4.11b that I consider to be bugs. I created an object of type A and I found out that some parameters cannot be configured or do get lost when I reload STD.

    First of all, here is one such parameters:

    <ParameterVariable name="rInput" hierarchy="Input" refId="ATMOxPID_rInput" varType="LREAL" textEn ="bla bla." textDe="bla bla." subtreeInstanceSpecific="True" />

    Now I have an object a. I cannot link object a's parameter to variables of object a's unit. I can select them in OES, but after I do the parameter is cleared again.

    I can link object a's parameter to the variables of object b's unit though, where object b is also of the same object type. But if I do that, then after reload STD the object parameter will be lost. If I link it to any other variable it seems to work fine.

    I think the problem is with the object's unit definition, which looks like this:

    <Unit refLink="A668CDB5-B088-4BC6-A09E-8151E9F1126A">
      <Condition comparator="EqualTo" value="True" refLink="ATMOxPID_ExportFb"/>
    </Unit>
    <Unit refLink="7558CD31-B708-46CF-BB35-2426AC69D054">
      <Condition comparator="EqualTo" value="False" refLink="ATMOxPID_ExportFb"/>
    </Unit>

    I guess when I reload STD it fails to recognize which of the two units I am using at the moment it is reloading the parameters, so it thinks the variable stopped existing. But why it immediately deletes my parameter selection if I select my own unit, I don't understand at all.

    Anyway, do you think this will be fixed in the future? Or do you have some more insight into this problem?

    Thanks.

    1 REPLY 1

    nexidator
    Community Moderator
    Community Moderator

    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.

    Icon--AD-black-48x48Icon--address-consumer-data-black-48x48Icon--appointment-black-48x48Icon--back-left-black-48x48Icon--calendar-black-48x48Icon--center-alignedIcon--Checkbox-checkIcon--clock-black-48x48Icon--close-black-48x48Icon--compare-black-48x48Icon--confirmation-black-48x48Icon--dealer-details-black-48x48Icon--delete-black-48x48Icon--delivery-black-48x48Icon--down-black-48x48Icon--download-black-48x48Ic-OverlayAlertIcon--externallink-black-48x48Icon-Filledforward-right_adjustedIcon--grid-view-black-48x48IC_gd_Check-Circle170821_Icons_Community170823_Bosch_Icons170823_Bosch_Icons170821_Icons_CommunityIC-logout170821_Icons_Community170825_Bosch_Icons170821_Icons_CommunityIC-shopping-cart2170821_Icons_CommunityIC-upIC_UserIcon--imageIcon--info-i-black-48x48Icon--left-alignedIcon--Less-minimize-black-48x48Icon-FilledIcon--List-Check-grennIcon--List-Check-blackIcon--List-Cross-blackIcon--list-view-mobile-black-48x48Icon--list-view-black-48x48Icon--More-Maximize-black-48x48Icon--my-product-black-48x48Icon--newsletter-black-48x48Icon--payment-black-48x48Icon--print-black-48x48Icon--promotion-black-48x48Icon--registration-black-48x48Icon--Reset-black-48x48Icon--right-alignedshare-circle1Icon--share-black-48x48Icon--shopping-bag-black-48x48Icon-shopping-cartIcon--start-play-black-48x48Icon--store-locator-black-48x48Ic-OverlayAlertIcon--summary-black-48x48tumblrIcon-FilledvineIc-OverlayAlertwhishlist