By default, when a history extension is added to a component, a history format default string is set to the following: “%parent.name%”. This string automatically names any histories with the name of the parent component and appends a sequential number to additional names, as necessary. For example, a history extension on a NumericWritable component will, by default, create a history name “NumericWritable” - then if that component is duplicated, the name for the history will be duplicated and incremented to “NumericWritable1”. You may add a literal name in front of, or after, the “%parent.name%” string, as shown in Figure 170, to customize it without losing the automatic naming feature.

If you use a literal name and not a script to name a history, you lose the automatic incrementing feature that the script provides. Duplicating extensions that have a literal name duplicates the exact literal name and therefore creates an invalid (non-unique) name. In this case, you must rename each duplicated history manually to create a unique name and avoid a fault condition.

As described in Configure history extensions, and illustrated in Figure 169, history names are part of the unique history extension property “Id”. When you rename a history at the history extension, you are renaming the history at its “source”. Therefore, the history configuration and the history Id both change. This concept is illustrated in Figure 171.

If, however, you rename a history in a “history space” view, such as under the history space node in the nav sidebar, or in the nav container view, you are changing the name of the history as it has been saved in the history space–not at the configuration (or origination) level. Therefore, the history Id is not changed and the history extension continues to produce records under the original history name as long as that history extension is active and enabled. This results in a history “split”; the newly-named history is no longer updated, as of the time of the renaming, but it contains all the records up to that time. In this scenario, a history under the original name begins with the first record after the renaming and continues recording as configured. This concept is illustrated in Figure 172.