PlatformServices binding and link caveats
Because any station’s PlatformServices are dynamically built upon startup, if binding its slots to Px widgets (or linking to other station components), be aware
of the following limitations/guidelines:
- Subscription behavior is unique to a station’s PlatformServices slots, in that property values initially load, but do not automatically update. To explicitly refresh such properties, you must invoke the “poll” action of the container for those properties.
For example, if on a Px page you bind a BoundLabel to the PowerMonitorService’s “Battery Good” slot, it will display text as “true” or “false.” However, this value does not update until the user right-clicks for the “Poll” action, which forces a fresh read.
Figure 115. Poll action on bound PlatformServices property
- Links from PlatformServices (and child slots) to other station components must use a source ord “slot path”, versus “handle”. Otherwise, after a station restart or host reboot, handle-sourced links may be lost. An example link being
edited to use slot path is shown in the figure above.
NOTE: Consider the “update limitation” before linking PlatformServices slots into other components that provide control logic. Linked slot values may well be outdated shortly after station startup, yet still “subscribed” and not marked as “stale.”Figure 116. From RelationSheet of target component, editing link to use slot path for source ord.
However, note that the station’s plugins (views) for the PlatformServices do provide updated property values, as they work in concert with the special polling used for platform-resident data.