Common uses for linked objects include

Common navigation tools that appear on several screens e.g. title bars.

SmartObjects.

Common footers.

When component designers need to create several objects that have the:

Exact same features (e.g. a title bar) they create (or edit) one object with the intent that it will be the source object for several linked objects.

Same internal functionality (for example, gauges), they can create a template that has the capability of being used as the source for a linked object.

Note: The template can use public variables whose values can be specific to each screen. This obviously provides the designer with extensive development flexibility.

When screen designers use linked objects provided by the component designer, they can create and configure application screens much more quickly than they can without the linked object. Instead of having to regularly place updated copies of the same object on different screens, all they have to do is create as many links as they want. CIMPLICITY automatically updates all the links when any change is made to the linked source object.

It is recommended that you take time to plan

Scripts and Procedures

Need to be executed for all the linked objects, write them for the linked source object.

Are unique to one or more linked containers, write them for the linked containers only.

Variables

Public and private variables impact

Variable	Reason	Link Container Variable Values
Public	Different links need to have different values.	Read/write
Private	Links need to be identical to the value entered in the linked source object's variable value field.	Read-only

If you are a component designer creating a linked source object, you have the difficult job of determining how specific public and private Variable IDs, procedures and scripts operate between the source object and its links. Once you make your choices, making the object a source for linked objects is easy.

 Guide: Sorting out the choices for linked objects:

The basic principles behind linked objects are straightforward.

An object can be either:

Copied to another location. In this case, the copy will not be linked to the original object

Or

Linked at another location.

An object can have from one to several variables. Variables can be either:

Public

or

Private.

Configuration written for linked source objects, including scripts or procedures, carry over to a linked object. However, the linked object's container can also have its own scripts or procedures.

A linked container is the shell of a linked object. You can configure properties for the container, such as movement and animation that, in addition to the linked properties, will affect the linked object's runtime behavior. This configuration has no affect on the linked source object.

Important

Because the linked container is a shell, it is a single entity. You cannot ungroup it, even if the source is actually a group of objects. Therefore, if any variables are public make sure they are at the highest group level. Once the linked container is placed on its target screen,  you will not be able to change any public variable value that is lower than the top level, because you will not be able to access it.

If a named object, including SmartObjects, is on a runtime-only screen (.cimrt ), you can only link it. You cannot copy it.

More information

Linked objects.

---