Inheritance Across Layers

New applications inherit object definitions and application properties from the layers on which they are based. They normally do not inherit instances of objects other than tags. For example, if your OEM layer has a custom report template, your new, derived application will be able to generate reports with that template, but you will not have a local copy of the code. The code remains in the OEM layer. (Tags are treated differently; the derived application will always be given its own copy of every tag in the OEM layer application.)

 

The same rule is generally true for pages, image files, device drivers, wizards and any other custom code. The new application remains dependent upon its OEM layers to supply various objects rather than becoming a complete, self-contained unit.

For an example, look at the list of application properties in a dependent application: properties with values set in this application are shown in black and can be changed. Properties whose values were set in the OEM layer are visible, and affect the dependent application, but they are not defined locally. Those properties can be changed, but only by creating a local copy, which will override the value from the OEM layer.

Pages and Widgets have different rules for inheritance

Use Care: Pages and widgets are handled differently from reports and wizard modules. If the OEM layer includes the source code of the page or widget, then upon opening the page or widget in the Idea Studio of the derived application, the default behavior is that the source code will be copied to the derived application. This creates a local override, which means that no further changes in the OEM layer will be seen in the derived application for that object.

 

For pages, you can control this behavior using the application property, AutoOverrideOEMPages.

When set to 0 (FALSE), developers working in derived applications will see the following prompt upon opening the Idea Studio for any page that exists (and for which there is source code) in the OEM application.

If overriding the page (default behavior) the source code is copied to the derived application.

If making a copy, the source code is copied and also renamed. The original page remains visible and usable, but its source remains in the OEM layer and updates there will be shown in the derived application. The copy is yours edit as you like. You are strongly advised against making the copy's name match the original. Doing so will only lead to confusion as you try to keep track of which page is the original and which is the copy.

 

Do not include source code files with your OEM layer unless you intend to make those objects editable in applications built on your layer.

Propagation of Changes Through Layers

You will need to deploy changes in the OEM layer if the AutoDeploy option has been disabled.

If the OEM layer has been installed at a site other than where development is being done, then updates to that layer should be made using Snapshot ChangeSets. If the dependent application (henceforth, "application") is modified using new features from the OEM layer, then it is essential that at the client site, the OEM layer be updated before the dependent application.

A restart of the application will be required if changes have been made any of the *.Startup file files or to source code files, excluding tags and pages. Any change that requires a restart of the OEM layer, including all properties marked "Restart required", will also require a restart of the application dependent on that layer.

Updates from the OEM layer to the application will be blocked by overrides in the application.

Tag instance parameters

Every tag instance in the OEM layer will be visible in the application and can be used there.

No restart required for updates: Changes made to tag parameters in the OEM layer are reflected immediately in the application excepting those that have been overridden.

Application overrides: Any property except the name can be overridden in the application.

Tag structure (child tags of defined types).

Every user-defined type in the OEM layer can be used to create new tag instances in the application.

No restart required for updates. Changes to the structure in the OEM layer will be reflected immediately in the application.

Application overrides. Possible, but discouraged. It is better to define a new type using the OEM structure as a component.
To redefine an OEM type you must have the Manage Types security privilege and the application property, CanRedefineOEMType, must be set to 1. (Review the warnings related to that property before proceeding.) New child tags can then be added and the Redefine Type command can be run in the application.
Updates to the type that are made in the OEM layer will continue to be seen in the application with one exception: Adding a child tag to the type definition in the application, then adding a child tag with the same name to that type in the OEM layer will cause an error. The child tag must be removed or renamed in the application.

Properties list of custom tag types

No restart required for updates. Changes to the structure in the OEM layer will be reflected immediately in the application.

Application overrides. Not possible under any circumstance.

Menus (page navigation, palettes)

The navigational page menu and the contents of all three palettes are stored as instances of Menu Item tags. The same rule applies as for other tag instances.

Pages and Widgets

Every page and widget in the OEM layer is visible and interactive in the application. No restart is required for updates. (Restart may be required in older versions of VTScada.)

Refer to notes earlier in this topic for the effect of AutoOverrideOEMPages.

Application properties

Every property in the OEM layer is visible in and applies to the application.

No restart required for updates, unless the property is marked "restart required". Changes to the property in the OEM layer will be reflected immediately in the application.

Application overrides. A copy can be made of any property. The properties list will still show the OEM version of the property in gray, including its current value, but the application's copy of the property will take precedence.

Code modules including reports

Every report and other module defined in the OEM layer can be used in the application.

Restart required for updates. (May vary.) Most module changes in the OEM layer will require a restart, therefore the application will also require a restart.

Application overrides. Possible by writing code. You must copy the module file (or create a new one of the same name) and declare it in the application's AppRoot.SRC file.

If the dependent application contains its own copy of a source code file or an application property, then it will ignore any changes made to those items in the OEM layer.
If the OEM layer is distributed without source code as a Snapshot ChangeSet, then the dependent application cannot obtain a copy of any of the source code. It can still set its own values for application properties. Changes to the installed OEM layer at the production site can be made only by applying a ChangeSet obtained from the development workstation.