Inheriting, Copying, Deleting€¦ · 04/2012 A5E03854708-01 Trademarks 1 Inheritance 2 Copying: General Definitions 3 Copying with the Navigator 4 Copy structure 5 Copying across

� �Inheriting, Copying, Deleting

___________________

___________________

___________________

___________________

___________________

___________________

___________________

___________________

___________________

___________________

COMOS

Platform Inheriting, Copying, Deleting

Operating Manual

04/2012 A5E03854708-01

Trademarks 1

Inheritance 2

Copying: General Definitions 3

Copying with the Navigator 4

Copy structure 5

Copying across projects 6

Cross-class copying 7

The Object Matcher 8

Delete 9

User interface reference 10

Legal information

Legal information Warning notice system

This manual contains notices you have to observe in order to ensure your personal safety, as well as to prevent damage to property. The notices referring to your personal safety are highlighted in the manual by a safety alert symbol, notices referring only to property damage have no safety alert symbol. These notices shown below are graded according to the degree of danger.

DANGER indicates that death or severe personal injury will result if proper precautions are not taken.

WARNING indicates that death or severe personal injury may result if proper precautions are not taken.

CAUTION with a safety alert symbol, indicates that minor personal injury can result if proper precautions are not taken.

CAUTION without a safety alert symbol, indicates that property damage can result if proper precautions are not taken.

NOTICE indicates that an unintended result or situation can occur if the relevant information is not taken into account.

If more than one degree of danger is present, the warning notice representing the highest degree of danger will be used. A notice warning of injury to persons with a safety alert symbol may also include a warning relating to property damage.

Qualified Personnel The product/system described in this documentation may be operated only by personnel qualified for the specific task in accordance with the relevant documentation, in particular its warning notices and safety instructions. Qualified personnel are those who, based on their training and experience, are capable of identifying risks and avoiding potential hazards when working with these products/systems.

Proper use of Siemens products Note the following:

WARNING Siemens products may only be used for the applications described in the catalog and in the relevant technical documentation. If products and components from other manufacturers are used, these must be recommended or approved by Siemens. Proper transport, storage, installation, assembly, commissioning, operation and maintenance are required to ensure that the products operate safely and without any problems. The permissible ambient conditions must be complied with. The information in the relevant documentation must be observed.

Trademarks All names identified by ® are registered trademarks of Siemens AG. The remaining trademarks in this publication may be trademarks whose use by third parties for their own purposes could violate the rights of the owner.

Disclaimer of Liability We have reviewed the contents of this publication to ensure consistency with the hardware and software described. Since variance cannot be precluded entirely, we cannot guarantee full consistency. However, the information in this publication is reviewed regularly and any necessary corrections are included in subsequent editions.

Siemens AG Industry Sector Postfach 48 48 90026 NÜRNBERG GERMANY

A5E03854708-01 Ⓟ 04/2012 Technical data subject to change

Copyright © Siemens AG 2012. All rights reserved

Inheriting, Copying, Deleting Operating Manual, 04/2012, A5E03854708-01 3

Table of contents

1 Trademarks ............................................................................................................................................... 7

2 Inheritance................................................................................................................................................. 9

2.1 Definition of the single methods.....................................................................................................9 2.1.1 Digression: Inheritance for engineering objects.............................................................................9 2.1.2 Definition: Hierarchical inheritance ..............................................................................................10 2.1.3 Definition: Referencing.................................................................................................................11 2.1.4 Definition: Linking.........................................................................................................................13 2.1.5 Definition: Inheriting via the Catalog tab ......................................................................................15

2.2 Application....................................................................................................................................15 2.2.1 Hierarchical inheritance ...............................................................................................................15 2.2.2 Setting a reference (link)..............................................................................................................15 2.2.3 Setting links..................................................................................................................................16 2.2.4 Inheriting via catalog attributes ....................................................................................................16

2.3 Check in object ............................................................................................................................17

3 Copying: General Definitions ................................................................................................................... 19

3.1 Copying on a report .....................................................................................................................19

3.2 The constituent parts of an object................................................................................................19

3.3 The copy amount .........................................................................................................................19

3.4 References...................................................................................................................................21 3.4.1 Allocation of objects .....................................................................................................................21 3.4.2 Definition and classification..........................................................................................................22 3.4.3 Special reference types ...............................................................................................................24 3.4.4 Alternative solutions.....................................................................................................................25

3.5 Extended copy amount ................................................................................................................28

3.6 Comparison of copying methods .................................................................................................29

3.7 Other sections for copying ...........................................................................................................30 3.7.1 Copying the system project..........................................................................................................30

4 Copying with the Navigator ...................................................................................................................... 31

4.1 Within the project .........................................................................................................................31 4.1.1 Functional scope..........................................................................................................................31 4.1.2 Application....................................................................................................................................33

4.2 Copying with project switch..........................................................................................................34 4.2.1 Functional scope..........................................................................................................................34 4.2.2 Application....................................................................................................................................36

5 Copy structure ......................................................................................................................................... 37

5.1 Scope of copying .........................................................................................................................37

5.2 Application....................................................................................................................................40

Table of contents

Inheriting, Copying, Deleting 4 Operating Manual, 04/2012, A5E03854708-01

5.2.1 Required rights............................................................................................................................ 40 5.2.2 Preparing the copy operation...................................................................................................... 40 5.2.3 Editing ......................................................................................................................................... 41 5.2.4 Concluding the copy operation ................................................................................................... 44

5.3 Special cases regarding Projections / Projection prohibitions .................................................... 44

6 Copying across projects........................................................................................................................... 45

6.1 General........................................................................................................................................ 45

6.2 Scope of copying......................................................................................................................... 45

6.3 Application................................................................................................................................... 47

7 Cross-class copying................................................................................................................................. 49

7.1 General........................................................................................................................................ 49

7.2 Scope of copying......................................................................................................................... 49

7.3 Use .............................................................................................................................................. 51

8 The Object Matcher ................................................................................................................................. 53

8.1 Scope of copying......................................................................................................................... 53

8.2 Function mode ............................................................................................................................ 54 8.2.1 Color scheme .............................................................................................................................. 54 8.2.2 Allocation of objects .................................................................................................................... 55 8.2.3 Comparison of objects ................................................................................................................ 55 8.2.4 Summary of the most important points ....................................................................................... 57 8.2.5 Documents special case ............................................................................................................. 57

8.3 Application................................................................................................................................... 58 8.3.1 Comparing objects from different projects .................................................................................. 58 8.3.2 Comparing objects from the same project .................................................................................. 60

8.4 Context menu.............................................................................................................................. 61

9 Delete ...................................................................................................................................................... 63

9.1 Deleting objects via the user interface ........................................................................................ 63 9.1.1 Overview ..................................................................................................................................... 63 9.1.2 Checklist when deleting .............................................................................................................. 64

9.2 Deleting without the COMOS interface ....................................................................................... 65

9.3 Deleting in working layers and in the history management ........................................................ 65

9.4 Deleting documents .................................................................................................................... 66 9.4.1 Deleting documents .................................................................................................................... 66 9.4.2 Protecting documents against deletion ....................................................................................... 66 9.4.3 Deletion in interactive reports ..................................................................................................... 66 9.4.4 Reference documents and document groups............................................................................. 67

9.5 Deleting in the Object Browser ................................................................................................... 68 9.5.1 Deleting columns......................................................................................................................... 68 9.5.2 Delete rows ................................................................................................................................. 68

9.6 Miscellaneous ............................................................................................................................. 69

10 User interface reference .......................................................................................................................... 71

Table of contents


10.1 Object Matcher.............................................................................................................................71

10.2 Copying across projects: Extended .............................................................................................73

Table of contents



Trademarks 1Trademarks

Registered trademark: COMOS®

Trademarks



Inheritance 2

This section covers the mechanisms by which information can be transferred automatically within COMOS from one object to other objects.

2.1 Definition of the single methods All information that is collected on the tabs of the base objects, or in other words, properties and collections, can be transferred and inherited. Examples of collections are attributes, connectors, elements, etc.

2.1.1 Digression: Inheritance for engineering objects In principle, the same terms are used in the case of engineering objects, but completely different mechanisms are described there.

Hierarchical inheritance There is no hierarchical inheritance in the case of engineering objects.

Referencing There is the "Reference" field in the properties of an engineering object that connects the engineering object with a base object. From a technical point of view, this is similar to the use of "References" on the properties window of base ""objects, except that only a portion of the data is transferred from the base object to the engineering object, while in the case of base objects all the information is transferred. For example, the "Symbols" and "Usage" tabs that are required for administration are not available in the planning view.

Linking A link is also called a "reference" in the case of engineering objects. Links can be created within an engineering project, but information is not collected, unlike within the base project. Links within engineering objects thus represent nothing more than an alternative access point for the object.

So much for the engineering view, the following details relate to the base data.

Inheritance 2.1 Definition of the single methods


2.1.2 Definition: Hierarchical inheritance Inheritance can also be called "1-to-n inheritance", since an object can have any desired number of "children," but each object only has one "parent object."

In the case of hierarchical inheritance, new objects take the properties and collections of the "parent object" that is located higher in the hierarchy. If any information of the "parent object" (also called parent") is changed, this change also takes effect for all "child objects".

If information was inherited, as shown above in the example for "Power," this information can be supplemented and modified on the lower hierarchy levels. A value could be assigned to the "Power" property or the "description" is modified. In this case we refer to a property that has been checked in. See also section Check in object (Page 17).

Please note: if the name of the attribute is changed at a higher level, then the previously checked in properties turn out to be useless. Avoid changing the name of an attribute that has already been checked in somewhere else.

This inheritance always takes place, and automatically. This is shown by an "E" in the Status column of the list mode. A reference interrupts the original inheritance chain at this point and inserts a new one. See also section Definition: Referencing (Page 11).



Exclusions Restrictions on inheritance at CDevice:

● Folder ("IsFolder")

● Virtual group ("Virtual")

Only available for elements.

● Inheritance mode

Only available for elements.

● Visible for all users ("Visible")

● Creation option ("CreateOption") (Inheritance only via base object)

Reason: A typical factor of the above-mentioned properties is that they should be changed at the next level, or indeed, need to be changed. Example: "Creation option". If "Structure" is selected here, child objects are created in the engineering view instead of this object. However, to do this, the "Structure" property may not be activated in the Child objects.

Thus, the "Structure" property can only be used if the objects that are located underneath it do not have this property. Inheritance of the "Structure" property would be counter-productive.

2.1.3 Definition: Referencing A reference transports all information that can also be inherited. (The management of the rights structure is completely independent from this, although this also deals with the question of "inheritance").

In the case of references, an object receives the information (properties and collections) from an object that is hierarchically located in another branch of the tree structure. If you change an attribute of the source object, for example, this change also takes effect for all objects that have a reference to this source object.

References also have a 1-to-n relation, since an object can serve as the source of a link as many times as desired, but each object can only have one "reference source object."



A reference interrupts the inheritance chain:

Note

Note that the attributes in the different branches can of course have the same name.

There are two options, which are references from a technical point of view, but differ in their handling. the reference to another base object, and an assembly reference.

Base object reference A reference to a base object is initially serves to take over all information of the other base object, but also still to be able to extend of modify the current base object. An item of information can be checked in and then be modified.

Attributes that have been transferred by means of a reference are checked in upon a change, just as for inheritance.

An assembly reference (see below) overwrites a base object reference.



Assembly reference The current base object can no longer be modified in the case of a assembly reference. All input fields are blocked, and it is not possible to check in any information. In practice, an assembly reference is used to set up a reference to a predefined group of engineering objects.

In order to understand this, you need to know that a base object does not necessarily need to be located within the base project and an engineering object does not necessarily need to be located within the engineering project. It is possible to create and wire engineering objects in the base project and to prepare them in any way.

However, the engineer cannot access the engineering objects from the base project later in the engineering project. A "negotiator" is required to make these prepared engineering objects accessible. An assembly reference is used for this purpose.

In other words: the base object only serves as a "container" for the module; and for that reason it is also unnecessary to change the information that were transferred from the assembly. Logically, you cannot do that with an assembly reference either.

An assembly reference overwrites a base object reference.

You find additional information on this topic in the "COMOS Administration" manual, keyword "Templates/Assemblies".

2.1.4 Definition: Linking Links are not base objects in their own right, but from a programming point of view, merely objects of type "CLink". If a link is affected in any way, this change takes effect on the original (and is visible at all connections of this original). Technically speaking, this concerns an "inheritance via Backpointer Clink": By contrast with the two previously introduced methods, information is not transported forwards here, instead only backwards.

Links are n-to-1 relations, since a link can be created at any desired number of locations and each link adds information to the original.

If links exist to an object, the inheritance mechanism (alternatively, the reference mechanism) is not interrupted: the object retains both the inherited information (or transferred by a reference) as well as all the information that arrive at the links.

Effect

● All collections, such as attributes, are transferred

● Its own properties are not transferred, e.g. description, label.



Note

Note that links can be switched to active or inactive within the Navigator (mouse command "Inheritance active via this link").

All information is visible everywhere, both in the original of the object and also in all links. Please note: if you change the inherited information, you do not change the "source" (it remains unchanged here), but you check in the information and modify it locally. See also section Check in object (Page 17).

Inheritance 2.2 Application


2.1.5 Definition: Inheriting via the Catalog tab

"Catalog attribute" field If tabs are linked via the "Catalog attribute" field, then the attributes on the tabs are also inherited.

This linking of a tab has the additional result that the hierarchical inheritance of owners is broken off for this tab. The effect is the same as the known effect at "References" for base objects: a reference breaks the inheritance chain from above, and it is only possible to inherit from the reference source.

The sole difference here: Inheriting from the owner is only broken off for this special tab.

2.2 Application

2.2.1 Hierarchical inheritance Hierarchical inheritance is an automatic mechanism and is not set manually. The only way to prevent inheritance from an "owner" (also called a "parent") is to set up a reference (see the next section).

2.2.2 Setting a reference (link) A reference is set via the "Properties" window of a base object.

Procedure 1. Select the "Data" tab in the properties of a base object.

2. Drag the object from which the attributes are to be transferred by reference into the "Reference" input group. You can drop the object at any desired location within the frame.

Result ● Attributes that are created on the object itself are retained.

● A reference transfers the attributes of the referenced object. This also includes those attributes which the referenced source object has itself inherited.

● The hierarchically-inherited attributes of the object are lost due to the referencing.

If you delete a reference, the hierarchical inheritance applies again.

Inheritance 2.2 Application


2.2.3 Setting links A link is created in the Navigator:

1. Copy the object

2. Change to the position at which the link is to be pasted.

3. Select the "Insert reference" context menu.

Attributes that are created on the object itself are retained. Inherited attributes are retained.

A link transfers the attributes that arrive at the link. This includes any attributes that the link itself inherited.

The "Inheritance active via this link" context menu command can be used for such references to base objects. Inheritance via the reference (link) can be switched on or off with the aid of this command. Activation is indicated by a tick in the context menu.

Rules concerning usage ● The links should not be located in the same subtrees, as this could cause undesirable

effects such as infinite loops, etc.

● The names must not be identical on the tabs.

– If the objects are located hierarchically under each other, then each name exists only once.

– If the objects are located within different subtrees, identical names can be allowed, since a unique source is available for each one

– However, whenever links are used, the user must ensure that there are no tabs with identical names.

2.2.4 Inheriting via catalog attributes Catalog attributes can originate from the base project or from an engineering project. They exist for attributes and attribute tabs:

● Properties of an attribute, "General" tab, "Catalog attribute" field.

● Properties of an attribute tab, "General" tab, "Catalog attribute" field.

The "Catalog attribute" field has the same meaning as the "Reference" options group in the base object, which has already been pre-selected. The effect is the same in both cases: the object / the attribute only serves as a container and all information is taken from the linked object.

If there is an "@Y Attribute catalog" base object within the current project, it is selected at first when you click on the selection of the catalog attribute.

Inheritance 2.3 Check in object


2.3 Check in object The following objects can be inherited and thus be checked in:

● Attributes

● Connectors

● Symbols

● Elements

● Documents

Devices can have attributes that were defined in a higher hierarchical level and are to apply for underlying levels. This is displayed by an "E" in the status column of the list view.

If an inherited attribute is to be modified, it has to be converted to an own attribute of the device. This procedure is called "checking in." Checking in is done automatically by the system.

Inheritance and checking in are done in principle at the level of the items: Items are not to be confused with the "Elements" tab). However, a further distinction is made as to which "Properties" of the items were actually modified. This means that the "Value" property can be checked in, while the "Control properties" property continues to be inherited. Only modified properties are uncoupled from the higher hierarchical levels.

Note

Note that if the name of the attribute is modified at a higher hierarchical level, the properties previously checked in will turn useless. Avoid changing the name of an attribute that has already been checked in somewhere else.

● Mark an inherited attribute in the Navigator (indicated by a black arrow at the top left)

● Right-click, "Properties" context menu

● The arrow changes to white after a change (checked in attribute).

After confirmation, the inherited attribute is definitively checked into the device and thus becomes an own attribute of the device.

Checked in attributes are marked with a "P" in the status column.

Note Although check in is done at the item level, an additional distinction is made as to which

properties were modified. The checked in items (such as attributes) continue to inherit information at the properties level that is unmodified.

All properties can be changed, except for the name.

Inheritance 2.3 Check in object



Copying: General Definitions 33.1 Copying on a report

You find additional information on this topic in the "Reports - Basic Operation" manual, keyword "Copying and inserting on the report".

3.2 The constituent parts of an object In the broader sense, an object consists of the following components:

Quantity number Component 1 The object itself 2 Properties at the object itself:

Name, label, description, etc. 3 Possible inherited properties:

All properties that are taken over from the inheritance source 4 Collections at the object itself:

Set of subordinated objects, set of attributes, set of connectors, etc. 5 Possible inherited collections:

All collections that are taken over from the inheritance source 6 References:

Links to other objects

These components are handled in different ways by the different copy methods. In the following, the components are defined to the extent that is necessary for an understanding of a copy operation.

3.3 The copy amount Each copying operation starts with the marking of an object. Fundamentally speaking, each copying method copies quantities 1., 2. and 4.: the object itself, the object’s own properties (OwnProperties) and the object’s own collections (OwnCollections). See also section The constituent parts of an object (Page 19).

This minimum amount of information is called overall the "amount to be copied". To put it simply, you define an amount to be copied as follows:

Amount to be copied = The marked object and all objects located underneath it.

Copying: General Definitions 3.3 The copy amount


Multiple selection There are small differences in a multiple selection: a number of copying procedures summarize all the marked objects into a single amount to be copied, while other procedures handle the marked objects individually and make independent amounts to be copied. There is more on this in the relevant sections.

Inherited information is recalculated based on the new owner.

Quantities 3. and 5. are not copied. To be more precise, this information also cannot be copied because it is in fact "not there" but only has validity for this object as well. In many cases inherited information is displayed as well in the Navigator at the object, but because of this it is nonetheless still not a "genuine" constituent part of the object.

This rule has no effect in the case of engineering objects, since inheritance is very restricted in their case (through the base object pointer).

However, unexpected things can happen with base objects, since the inheritance mechanism plays an important role here. If a base object has just been created, it then first of all inherits from the inheritance source nearly all the information, and the class as well, for example. You can recognize an inherited class from the fact that the entry is shown italicized in the "Class" drop-down menu.

The inherited information is recalculated when a base object is copied. If the class was inherited, this may change according to the new owner. (It also can only be copied one to one once the information has been checked in.)

Note

Inherited information is not copied. Inherited information is recalculated on the basis of the new owner.

A number of copying methods offer the option to set up the owner structure as well if it does not already exist in the target project. In that case the most important inherited information is retained because the "new" owner structure matches the "old" owner structure in the relevant information.

Please note: it is not possible to say in general when which object information will be copied and when which inherited object information is recalculated, because that depends on the relevant data structure in the target project. There is more on this in the relevant sections.

Copying: General Definitions 3.4 References


3.4 References The individual copying methods primarily differ through their handling of references.

3.4.1 Allocation of objects

References are allocations of objects. 1. This allocation can affect objects that are within the amount to be copied. In that case the

references to the object that has been copied as well are retained.

Example: In the following case the transformer and the device are joined by connectors. From a technical point of view, this connection is nothing other than a reference. Since both the objects are within the amount to be copied, the reference is correspondingly retained (the connectors of the two copied objects are joined):

Note

References that point to objects within the amount to be copied are retained.



2. References can "point out of the amount to be copied". This means: the referenced object is not within the amount to be copied.

Example: A unit is marked and copied; thus the amount to be copied is a subset of the "Units" tab. If, for example, the device possesses a location pointer, the referenced location is then on another tab and is thus not within the amount to be copied:

References can "point out of the amount to be copied". This means: the referenced object is not within the amount to be copied.

Example: A unit is marked and copied; thus the amount to be copied is a subset of the "Units" tab. If, for example, the device possesses a location pointer, the referenced location is then on another tab and is thus not within the amount to be copied:

3.4.2 Definition and classification

Definition of the term "references" References are allocations of objects. This allocation can simply have a logical function or it can result in comprehensive changes to the object. The term "references" is an umbrella term, and for certain types of information the terms connections, pointers or links are used as well. But in all these cases it always involves references.



Some examples: ● Connections (connecting information between two connectors) in engineering objects are

references.

● The unit pointer and the location pointer are examples of references that are more of a logical nature. Thus it should show the logical allocation of a device to a unit or a location although the device itself is not changed. Often these references are used in Evaluation Reports to determine the full name or full labeling of a device.

● On the other hand, the base object pointer radically changes an engineering object.

Reference types can be divided into two large classes:

● References that point to "engineering objects in the broader sense" (the project’s own references) and

● References that point to "base objects in the broader sense".

Engineering object references This groups includes, for example, unit pointer and location pointer, (closed) connections.

Note

Note that engineering object references can occur not only in an engineering project but also in a base project! An example of this is the modules pointer to CDevices.

Note

Referenced engineering objects do not have to be located within the engineering project. But they are always located in the same project as the objects of the amount to be copied.



Base object references These are references that point to "base objects in a broader sense".

"Base objects" in the narrower sense are only CDevices, or in other words, those objects that are created as the basis of an engineering object. In the broader sense, additional data is taken into the term:

● All objects on the "Base objects" tab, regardless of whether or not they are of system type "CDevice". All lists, standard tables, document types, units groups, etc.

● These objects are primarily located in the base project, but sometimes also in the system project or even in the engineering project.

Note

Please note that base objects in the broader sense are not necessarily always automatically located in the base project! For example, it is permitted to create local base objects (instances), or in other words, base objects within the engineering project. Document types, for example, are also permitted to be located in the system project. In other words: the referenced objects can be located outside the project in which the copying operation took place.

Note

Base objects in the broader sense can be located either in an engineering project, in the base project or in the system project. They also do not need to be located in the same project as the objects of the amount to be copied.

Reference types There is a list of all references in the annex. There it is also stated whether an engineering object reference or a base object reference is involved.

3.4.3 Special reference types Connectors and the alias pointer form a 1-to-1 reference. These are relationships that are clearly and unambiguously visible from each view:

● Each connection has exactly one counterpart and not just any one, but a very specific one. It is never permissible to have two connectors that both point to the same counterpart connector.

● Each object has exactly one alias object and not just any one, but a very specific one. It is never permissible for another object to use this alias object.

The special points are likewise given in a list in the annex.



3.4.4 Alternative solutions

In the case of objects within the copy set If a referenced object is located in the copy set, then the reference will no longer point to the original object but instead to the copy in the copy set

For "references pointing outwards" If an object has a reference, and this reference points to an object that is not part of the copy set, there are five options:

1. The reference to precisely this object is retained

2. the referenced object must be copied as well, although it is not in the located in the copy set (bringing over the objects) or

3. If technically possible: the reference can be transferred (projection), or

4. the reference is deleted, or

5. the copy process is blocked.

There will be no "open" reference.

Regarding option 2: Objects that have been brought over

In the case of option 2.: "Copy referenced objects as well", we refer to "objects that have been brought over". Here the referenced object itself is copied as well, but not necessarily completely. Thus in the case of objects that have been brought over it is necessary to restrict how much information is copied as well to prevent the quantity of objects that have been brought over from growing excessively due to the iterative process

An object that has been brought over can itself contain all the information presented. See also section The constituent parts of an object (Page 19). In this case it is primarily the collections and the references that are of interest.

These collections are brought over (created) in the copy operation:

Table 3- 1 Information taken from the referenced object

System type Collections All objects Attributes Base objects (CDevice) Attributes OwnElements OwnDevSymbols OwnSuppliers OwnConnectors OwnDocuments Documents Attributes Documents DocObjects Devices



System type Collections Standard table Standard values Standard value DevSymbols

Objects that have been brought over can in turn bring over other objects as well. This can be made clear with the example of the base object: a base object can have a collection of documents that are then likewise brought over.

Figure 3-1 Objects that have been brought over in the case of collections (example)

There is a similar mechanism for the references of objects that have been brought over. Broadly speaking, the rule is as follows:

P-references are lost and S-references are retained when copying the structure.

The references are retained and bring over additional objects when copying across projects and when using the Object Matcher.

Regarding option 3: Projection

In the case of option 3.: "references are transferred", this refers to "projected objects".

A projection is the information that there is no need to create a new object in the target for the referenced object because there already is an existing object in the target that can be used as the reference. This is done by comparing the object that has been brought over with a potential target object. The following information must match:

● Name

● Complete path



● System type

● Class

Example:

Figure 3-2 Successful projection

The comparison produces the following:

In brought over Object In the target object Name Transformer Transformer ✓ Path UnitA > DepartmentA UnitA > DepartmentA ✓ System type Device Device ✓ Class Device Device ✓

Example 1 regarding projection

Copying: General Definitions 3.5 Extended copy amount


However, in the following case the projection of "Transformer" fails:

Figure 3-3 Unsuccessful projection

In brought over object In the target object Name Transformer Transformer ✓ Path UnitA > DepartmentA UnitA > DepartmentA - System type Device Device ✓ Class Device Device ✓

Example 2 regarding projection

3.5 Extended copy amount The main difference of the individual copying methods is in the extended amount to be copied.

Extended amount to be copied = amount to be copied + objects that shall be brought over.

Copying: General Definitions 3.6 Comparison of copying methods


3.6 Comparison of copying methods If the referenced object is not in the amount to be copied, then...

Table 3- 2 Quick overview of copying methods

Simple copying Copy structure Copying across projects

Object Matcher

Minimum amount to be copied

X Lists, tables, unit systems: Not through the Navigator, but in dialog windows

X Extended object amount: connector tracking, some BackPointer collections

X Some objects are not permitted as root

X Extended object amount: Lists, tables, unit systems:

Base object pointers(S-references)

(X) Base object pointer is searched for. The copying operation is blocked if the pointer to this precise object cannot be retained.

X (otherwise created)



Connection reference - X X X Alias pointer - X X X Engineering object references (S-references)

- Project not changed: is retained Project changed: is lost

X The unit to which the pointer points is searched for on the basis of the "FullName". If the unit is not found, it is created. The result initially appears in an additional Navigator for intermediate editing.

X The unit to which the pointer points is searched for on the basis of the "FullName". If the unit is not found, it is created (incompletely).

X The unit to which the pointer points is searched for on the basis of the "FullName". If the unit is not found, it is created (incompletely).

References in the case of objects that have been brought over

There are no objects that have been brought over.

(X) P-references are lost. S-references are retained

X Are retained and bring additional objects over.

X Are retained and bring additional objects over.

Create hierarchy - X X X DocObjs X

DocObj depending on mode.

X "DocObj depending on mode."

X "DocObj depending on mode."

X DocObj depending on mode. -> Effect on "sameness" of data after the copying!

Multiple selection - Only apparently!

X - -

Quick X - X - Manual intermediate editing

- X (X) -

Copying: General Definitions 3.7 Other sections for copying


Simple copying Copy structure Copying across projects

Object Matcher

Rights query at the target

(X) Create

X All rights are required; but not necessarily Admin



Special points Revisions are deleted. Dialog window remains open

Dialog window remains open both allocation and object matching

3.7 Other sections for copying

3.7.1 Copying the system project The system project contains lists and information that run across projects. In particular this also applies to the underlying lists that are required for COMOS to function and which are supplied in the scope of delivery.

You find additional information on this topic in the "COMOS Administration" manual, keyword "Copy system project".


Copying with the Navigator 44.1 Within the project

4.1.1 Functional scope

Minimum amount to be copied All copying functions in COMOS have a common minimum scope of copying (constituent parts 1., 2., and 4.):

● the object itself,

● all the object’s own properties (OwnProperties), and

● the object’s own collections (OwnCollections).

See also section The copy amount (Page 19). In other words: everything that was not inherited is copied. Inherited information is recalculated based on the new owner.

Furthermore, the copying methods differ in the way that references are handled.

Handling of references in the case of simple copying

● Engineering object references

– P-references with a 1-to-1 relation

Connectors

– The referenced object (namely, the device with the counterpart connector) is part of the amount to be copied: The reference is retained to the extent that it points to the object that has just been created by the copying and not to the originally referenced object.

– The referenced object is not a constituent part of the amount to be copied: The reference is lost in the case of "simple" copying. In other words: if a connector had been joined previously, the connector is not joined to the copied object.

Alias pointer

An object that has been referenced by an alias pointer never becomes part of the amount to be copied, since the alias branch must be created directly under the project. Since the project itself cannot be copied by means of "simple copying" and a true form of multiple selection is also not possible, there is no way to simultaneously copy engineering objects and alias objects by using the simple copying function.

In other words: the alias functional scope is always lost in the case of simple copying.



– All other P-references (functional scope) without 1-to-1 relation

"Functional scope without 1-to-1 relation" means that there can be multiple objects that point to an object. Example: unit pointers, location pointers.

– The referenced object (for example, a cable that has been allocated to a connector) is part of the amount to be copied: the reference is retained and points to the copied object.

– The referenced object is not a constituent part of the amount to be copied: amount to be copied:

Exception to b): Cable reference that is lost in the case of a reference pointing outwards. In other words: if a cable had been allocated beforehand, the connector of the copied object has no cable information.

Base object references (all)

● The referenced object is part of the amount to be copied. You might expect as an example the base object pointer of an engineering object; but this does not cover all the possibilities that might occur. For that reason the CDevice pointer of the base object was chosen as an example; this is the reference that is input in the Reference field of a base object. CDevice pointer: The pointer is transferred appropriately and after the copying operation points to the object that had been copied as well and no longer to the original referenced object..

● The referenced object is not a constituent part of the amount to be copied. The CDevice pointer is retained and continues to refer to the original object after the copying operation.

Special handling of objects

● The DocObj

When an object is placed on a report, a DocObj is created in the structure tree that shows this placing. Please note: the DocObj is located underneath the report within the meaning of the object model but is displayed in the Navigator underneath the placed object. In connection with the copying operation, the only thing that is of interest is where the DocObj is located within the meaning of the object model.

If a DocObj is deleted, the object placed on the report is not lost completely: the report itself still possesses the information on what kind of object was placed, but the report no longer has any information as to which object it was concretely.

There are three ways to handle DocObjs when using "simple copying":

– Standard case: The DocObjs are deleted. When the document is opened for the first time after copying, new objects are then created according to the information of the report itself. In other words, the document no longer contains the original placed objects but instead the new objects that have been created. Where and how the objects are created is determined by the drawing type involved. To some extent it can be helpful to create the objects underneath the report, and to some extent the objects are created in parallel to the report.



– DocObjs are retained. If the placed object is likewise part of the amount to be copied, then after the copying operation the DocObj points to the new object that had been created by this copying operation. If the placed object is not in the amount to be copied, the DocObj then points to exactly the same object. The device is then placed twice: once on the original document and once on the document produced by the copying operation.

– The DocObjs are modified. A copy is automatically created in parallel with the placed object. If there was previously a placed "Indicator1", then after the copying operation there will also be "Indicator1_1". The DocObj points to the object that has just been created.

The mode that is set for a DocObj can be determined by the object interpreter. This is done by dragging the DocObj into the drag & drop field A and selecting the A.CopyMode command. As a result a number [1, 2, 3] is displayed that corresponds to one of the three above-mentioned cases.

Revisions are deleted in the case of documents.

4.1.2 Application Considering the limitations the default copying function is fast and simple. Select an object in the Navigator and select the "Copy" context menu with the right mouse button.

The object is copied with all its properties and collections onto the COMOS clipboard and can be pasted again at another position.

Please note: a common amount to be copied is not set up when making a multiple selection! The effect is the same as if the relevant marked branches had been copied individually. This is primarily of importance in the case of "references pointing outwards", since without the common amount to be copied the references are treated as "pointing outwards" by one of the marked branches in one of the other branches.

Moving versus Cutting The "Cut" and "Paste" function in Windows is familiar. Since COMOS wants to offer the known Windows functionalities, these functions have likewise been made available in COMOS. But they should not be used. The following combination should be used instead:

● "Copy" and afterwards

● "Move"

The "Copy" and "Move" combination is functionally identical to the "Cut" and "Paste" combination from the user's point of view but it offers greater safety in technical terms, since no objects can be lost.

Example: If an object is cut, it then only continues to exist on the COMOS clipboard. The clipboard is deleted without a safety prompt when COMOS is closed. But COMOS can always be closed with no risk when using "Copy" and "Move", since the original still exists in addition to the copy on the clipboard.

Copying with the Navigator 4.2 Copying with project switch


4.2 Copying with project switch

4.2.1 Functional scope From a technical point of view there is no difference between simple copying within a project and simple copying with a project switch. However, there are a number of special cases that are only visible to the user in the second case, the one involving a change of project. For that reason we refer at this point almost completely to the previous section and only cover these special cases here.

Minimum amount to be copied See also section Functional scope (Page 31).

Handling of references in the case of simple copying with a project switch


P-references are lost in the case of simple copying with a project switch.

Base object references

1. The referenced object (example CDevice pointer: the base object that was entered in the "Reference"" field of a base object) is part of the amount to be copied. After the copying operation the pointer points to the object that was copied and no longer to the object that was originally referenced.

2. The referenced object is not a constituent part of the amount to be copied, but it is precisely the referenced base object that can be found from the target. The pointer is retained and continues to point to the original object after the copy operation.

COMOS searches the associated base object in the following order:

– The base object is part of the amount of copied objects.

– Alternatively, it is searched for the base object in the target project.

– Alternatively, a search is made in the base project of the target project for the base object.



3. The copy function is blocked if neither 1. nor 2. is possible.

As an example, the case of the base object pointer:

– The base object pointer is the information on which base object the engineering object is based on. A precise object allocation is conducted; simply having the same name is not sufficient:

Figure 4-1 Prerequisite for the "simple copying": Same base objects

● In the left-hand case the "simple copying" was successful: the base objects are identical, since both projects point to the same base project.

● In the right-hand case "Object A" from project "HKS 51" can not be copied into project "HKS_new" because "HKS_new" has another base project "S01_new". There is also a "Device A" base object there, but this base object only ha the same name; it is not identical to "Device A" from "S01".

If all options should fail and the base data pointer would therefore be lost, the copying function is blocked. In such a case, you should copy across projects, and perhaps activate the "without references" option when doing so. This closest corresponds to the usual impression of what "simple copying with a change of project" constitutes.

Special handling of objects: See also section Functional scope (Page 31).



Other This procedure is not identical with "copying across projects"!

It is not possible to copy across databases.

4.2.2 Application

Copying within the Navigator The COMOS clipboard is independent from the project. In other words: an object in the clipboard is retained even if the project is switched. You can also take advantage of this effect during regular copying:

1. Copy an object

2. Switch the project

3. Paste the copied object.

"Move" is not available if the project has been switched.

Copying attributes The attribute values can also be copied across projects.

Copying using the additional Navigator tab

The use of an additional Navigator tab is somewhat more convenient.

The specialty here: The additional tab retains that previously opened project even with a project switch. For that reason the following procedure enables to carry out a simple copying operation from one project to another project:

1. Open the source project.

2. Select an object that you wish to copy or which contains objects that you wish to copy.

3. Drag&drop the object into a free area of the strip in which the other Navigator tabs are located.

An additional Navigator tab opens, which displays the corresponding part of the Navigator.

4. Open the target project.

5. Copy an object onto the additional Navigator tab via the context menu.

6. In the Navigator of the new project, mark the object under which the copied objects are to be pasted.

7. In the context menu of the object, select the "Paste" command.


Copy structure 5

With "Copy structure" one or more objects – regardless of whether they are base objects or engineering objects – are copied into a separate Navigator together with their structures and all their links, and are then available for editing. Hence there is a basic distinction between this function and "Tear off'": the links, etc., are not copied over as well when using the latter command.

"Copy structure" takes time and, above all, memory, since the objects are all duplicated for editing. If there are very large amounts of data, it is better to do without editing and to select Copy across projects instead.

5.1 Scope of copying

Minimum amount to be copied All copying functions in COMOS have a common minimum scope of copying (constituent parts 1., 2., and 4.): Everything that is not inherited or referenced is copied. Inherited information is recalculated based on the new owner. See also section The copy amount (Page 19).

Handling of references in the Object Matcher ● Engineering object references

P-references with a 1-to-1 relation

● Connectors

● The referenced object is part of the amount to be copied:

The reference is retained, both copies are linked to one another.

Copy structure 5.1 Scope of copying


● The referenced object is not a constituent part of the amount to be copied:

– The object is brought over and a projection is possible:

A projection in the target project is searched for on the basis of the FullName. Connectors are joined at the object to which the projection is made.

The connectors may not be joined in any other way.

– Example 1: Device A and Device B are connected: CP1 with CP1 and CP2 with CP2. Device A is copied, a Device B is found in the target project.

This Device B has four connectors, of which CP2 is already being used, while the other three are still free. Effect: there is no projection since CP2 is already being used, and instead an attempt is made to create a new Device B. The name is incremented to prevent a collision of names (because there is already a Device B in the target project!). Result: an object Device B_1 is created in the target project.

– Example 2: Device A and Device B are connected: CP1 with CP1 and CP2 with CP2. Device A is copied, a Device B is found in the target project.

This Device B has four connectors, of which CP4 is already being used, while the other three are still free. Effect: it is projected. Once the structure is copied, connectors CP1, CP2 and CP4 at Device B are occupied.

– The object is brought over but a projection is not possible:

The referenced object is newly created. The name is incremented if it is not possible to make a projection because the connectors have already been allocated.

– Alias pointer

The object that is referenced by an alias pointer can be part of the amount to be copied if the alias branch was selected by means of multiple selection.

– The referenced object is part of the amount to be copied:

The alias pointer is retained, the device points to the copy of the alias branch.

– The referenced object is not a constituent part of the amount to be copied:


A search for the object is performed in the target project. See also section Alternative solutions (Page 25).

The alias object is not allowed to be referenced in any other way than an alias.


The referenced alias object is newly created. The name is incremented if a projection is not possible due to the use of an existing alias.

A projection is not possible if no object with a matching FullName can be found, or if a matching object exists but this object is already used as an alias object. Please note: In this case the alias object is nonetheless displayed in the Navigator in the "Copy structure to <project>" window as "Projection".

Copy structure 5.1 Scope of copying


● All other P-references

– The referenced object is part of the amount to be copied:

After the copying operation the pointer points to the object that was copied as well and no longer to the object that was originally referenced.



A search for the object is performed in the target project. See also section Alternative solutions (Page 25).


The referenced object is newly created.

● All base object references

– The referenced object is part of the amount to be copied. After the copying operation the pointer points to the object that was copied as well and no longer to the object that was originally referenced.


– The object is brought over and a projection is possible: The base object is searched for, and the pointer to the original base object is retained.

● COMOS searches the associated base object in the following order:

– In the target project.

– In the base project of the target project.

– The object is brought over but a projection is not possible: The referenced object is recreated within the target project as a base object. If the target project is an engineering project, the copy can also be a local base object.

Handling references for objects that are brought over ● S-references are retained.

● P-references are lost.

Specialties The Copy structure function contains a number of rules by which the amount to be copied is increased. In other words: normally the OwnCollections alone form the basis for generating the amount to be copied, but an additional evaluation is made with Copy structure:

● Connector tracing

"Copy structure" conducts an automatic connector tracing.

Example: A copy is made of "object A", which has six connectors, of which four are actually connected. The connectors that are joined lead to four objects that are now all included within the extended amount to be copied, either as a projection or as a new object to be created.

Copy structure 5.2 Application


The first of these four objects also has four connectors joined to it. One of these is the counterpart to "object A", but the other three connectors point to three further objects. Each of these objects is included in the extended amount to be copied if it has not been included already.

Please note: If "Copy structure" is included in a quantity of data that is interlinked within itself in a complex way, the extended amount to be copied may get very large.

● BackPointerDevicesWithUnit, BackPointerDevicesWithLocation

The information as to which engineering objects (class Device) are joined within this unit or location. In other words: not only an engineering object "knows" with which unit it is linked; the unit also "knows" which engineering objects it is linked with to.

● BackPointerDocsWithUnit, BackPointerDocsWithLocation

As the previous item, but for documents.

5.2 Application

5.2.1 Required rights You must have all necessary rights (read, write, etc.) in the target project to be able to use "Copy structure". It is not essential to be logged in as administrator, but an administrator does of course automatically have all required rights.

5.2.2 Preparing the copy operation Call: Mark the object(s) and right-click on "Copy structure".

Multiple selection You can also select multiple objects and then select the "Copy structure" command.

Effect "Copy structure" copies one or several objects and their entire structure into a Navigator, starting with the marked node and including all links, in the "Copy structure to <project>" window.

Links are taken over automatically.

Note

Do not click on the "OK" button when using "Copy structure" within a project. The data must first be subjected to editing before you can close the copying operation.



Special preparations for "Copy Structure" with a project switch When the "Copy structure" command is executed it is aimed at the main Navigator. If the copying operation is concluded with "OK", the objects are created in the project that was visible at that point in time in the main Navigator.

Thus, this also produces the option to copy across projects:

1. Open the source project.

2. Select an object that you wish to copy or which contains objects that you wish to copy.

3. Drag&drop the object into a free area of the strip in which the other Navigator tabs are located.

An additional Navigator tab opens, which displays the corresponding part of the Navigator.

4. Switch the project.

The additional Navigator tab continues to display the content of the old project.

5. Select the "Copy structure" command on the additional Navigator tab.

The result of the copy process is executed in the main Navigator - and hence in another project.

It is still possible to edit the objects before the copying operation is actually executed, see the following. The changes only take effect once the objects are accepted in the main Navigator with "OK" or "Apply".

Result of the preparation The extended amount to be copied is constructed of the result and is transferred to the "Copy structure to..." dialog window.

5.2.3 Editing

Automatic editing: Projection As explained above in the "Purpose" section, as much of the information and properties of the copied object as possible should be adopted when using "Copy structure". At the same time, any existing information should be used as far as possible.

If Copy structure is executed, the extended amount to be copied is compared with the current project and all objects that can be allocated by means of FullName are offered as a projection. If the projection is accepted by the user, then no new object is created but instead the object that was found is used in the current project.

Projected objects can easily be recognized by the black arrow in the top left-hand corner:

A location that is projected. No new object is created when the copying operation is concluded, but instead an existing object is used.



A location that is not projected. A new object is created when the copying operation is concluded.

A projection is thus an item of information during the preparation for copying that indicates that it is not necessary to create a new object for a reference, but instead a reference can be made to an existing object.

The "Rename" and "Remove" commands are not available for projected objects, because the commands would have to have an effect through the projection on the existing objects in the data. However, the projection can be manually removed. A new object would be created without the projection and this potential object can be edited manually.

Inconsistency check In COMOS there are cases in which 1-to-1 connections are absolutely essential: With connectors, in COMOS's own alias naming system, for the implementation. Multiple connections could arise if there are inconsistencies, but these are strictly prohibited.

If there are any inconsistencies, the projection is not totally prohibited, but the projection is run first of all. (No objects are copied at this point in time.)

If it turns out during the actual copying that a multiple connection would be produced, then the copying action is permitted but a portion of the source information - precisely that portion of the information that would lead to a multiple connection - is discarded.

The deleted information is taken into the notification list.

Manual editing The projection can be removed manually if you want to create a new object in any case:

"Delete projection" COMOS tries to use existing objects as a default. If you want to create new

objects instead, select the "Delete projection" option. The new object is given as a default template the name of the original object. A new name can be assigned with "Rename". If there is a collision of names, the object name is automatically incremented when the copying operation is concluded.

If a projection is deleted within a hierarchy, then logically enough the projection is deleted for all objects lying underneath it. When the projection is deleted, a new object is created - and hence a new branch in the tree structure! Since the branch is new, there cannot be any existing objects beneath it onto which it would be possible to project.

Multiple selection It is also possible to select and edit multiple objects simultaneously.

If, nonetheless, you wish to use an existing object but not the object that was offered automatically, you can still change the projection by means of drag&drop.



For example, you simply drag a new location onto "S1". The result is that the object of the extended amount to be copied is displayed and in addition also the projection that was set manually:

Object "S1" is projected onto "S6".

This also enables to balance the number of hierarchical level (reduction of levels).

In the extended amount to be copied there is an object that was originally located on the fifth level of the structure tree. A projection is set on an object that is on the third level by means of drag&drop.

However, the relative order of the levels must still be retained. If the object related to another object which was hierarchically located higher, is not allowed to be at the same or lower level then the other object as a result of the level reduction.

A reduction in levels (the removal of objects) is only permitted if during the preparation for the copying there are no other objects located on that level and there are no pointers referring to them.

This sounds complicated, but it is simple enough in actual practice. If two projects have been set up in a very similar way, but an additional folder level was incorporated in the source project, for example, then all objects in the target can "move up one level". All relative superordinated and subordinated relationships are still retained in this case.

The original projection to the existing object S1 can no longer be reproduced automatically. In other words: the automatic projection is carried out just once and at that very moment, since the extended amount to be copied is transferred to the "Copy structure to..." dialog window.

Of course, a manual projection can be carried out by using drag&drop, and this has the same effect. But if the user has conducted considerable editing afterwards in the case of an automatic projection, it is necessary to bear in mind that you cannot lightly discard all changes that were made and go back to the initial state.

A number of further editing commands are available for all objects that are not projected – and hence also for all objects for which the projection was removed manually.

The simplest form of post-editing is a change of name:

"Rename" The name for the newly created object. If there is a collision of names, the object

name is automatically incremented when the copying operation is concluded. An object for which there is a projection cannot be renamed. First of all the projection must be removed, and then a new name can be input for the object (which as a result is created as new). See below for more regarding the topic of "projection".

Another form of editing could be to manually exclude specific information from the transfer:

"Remove" The object is deleted (not created). If the object on which the "Copy structure"

command was used is deleted, copying does not take place. The command is not available for objects that are projected.

Copy structure 5.3 Special cases regarding Projections / Projection prohibitions


Please note: it is not possible to delete a single reference. When you call the context-sensitive mouse menu at a reference and select the "Remove" command, then not only the selected reference but also the referenced object is removed. Consequently all other references that pointed to this referenced object are lost as well.

It is up to the user to discard all editing done to date and to call "Copy structure" again.

5.2.4 Concluding the copy operation Confirm with ["OK"] or ["Apply"].

Objects that are not projected are created newly. If necessary, further objects are created, including the relevant hierarchy as applicable.

5.3 Special cases regarding Projections / Projection prohibitions The subordinated objects are likewise projected by a projection. Normally the name, path, system type and class are used as comparison criteria: projection is possible as a rule if there already is an object with precisely these criteria.

● Elements

In the case of "DeviceClassElement" (e.g., terminals) the next free element with the same prefix is searched for and projected instead.

Rules for objects that cannot be projected:

● Objects that are to be projected must be of the same system type and must have the same device class. In addition, they should not be inherited; this could be the case for elements and attributes. A projection cannot be performed if these conditions are not met; a new object is created in such a case. (At the moment the Copy structure function only works with non-inherited structures.)

● Elements placed on documents cannot be projected, i.e., DeviceClassElement with BackPointerDocObjs is not empty.

● Special case: It is not possible to project in the case of engineering objects if the BackPointer-DevicesWithImplementation collection is not empty. In this case the implementation pointer is set to display special points in the engineering technique. Example: Route.

● Engineering objects with joined connectors cannot be projected. Exception to the exception: Engineering objects with subclass "Potential".


Copying across projects 66.1 General

Copying across projects is intended to completely copy all objects – hence, including all references, connections, substructures, etc. – within a database from one project into another project. The type of the project is completely unimportant: You can also copy across project types, in other words, from a template project into an engineering project, etc.

You cannot execute the cross-project copy function within a project. You cannot copy from working layers either. If a working layer is active in the selected source project, copying is still done from the released area.

Rights See Copying across projects: ExtentedCopyRightForCurrentUser.


Minimum amount to be copied All copying functions in COMOS have a common minimum scope of copying (constituent parts 1., 2., and 4.): Everything that is not inherited or referenced is copied. Inherited information is recalculated based on the new owner. See also section The copy amount (Page 19).

Restriction Following objects cannot be used as source:

● Document objects

● Attributes

● Connectors

In other words: you cannot explicitly drag an attribute into the Source field. However, these exceptions also only apply to the initial point; these three object types can of course be copied as well in the case of all subordinated objects.

Handling of references when copying across projects

Projection for referenced objects: Just as for the copying of structures, a projection is also performed when copying across projects. However, this projection is not visible when copying across projects and also cannot be set again via drag&drop. However, there is a somewhat restricted alternative way to edit projections. See also section Copying across projects: Extended (Page 73).

Copying across projects 6.2 Scope of copying



See also section Scope of copying (Page 37).

Deviations: ● Alias pointer

The object referenced by means of an alias pointer can never be included in the copy set. Reason: the alias branch is located directly underneath the project. It is not permitted to copy the project itself by means of copying across projects, multiple selection is also not possible. This means that it is not possible to set up a copy set that contains both a device branch and the alias branch.





Handling references for objects that are brought over

References in objects that are brought over are retained and bring over additional objects.

Evaluated collections

● "CDevice

OwnSpecifications

OwnElements

OwnDevSymbols

OwnConnectors

OwnDocuments

CLinks"

● "Device

OwnSpecifications"

● "Document

OwnSpecifications

Documents

DocObjs

Devices"

● "StandardTable

StandardValues"

● "Specification

OwnSpecifications"

Copying across projects 6.3 Application


● "StandardValue"

● "DevSymbols"

Special points The structure of the source project from the project root (the globe) up to the marked object can be reconstructed in the target project with the help of the "automatically create hierarchy" option.

Difference from Copy structure:

In the case of Copy structure the hierarchy is copied first of all. The levels can be balanced by using drag&drop.

It is not specifically possible to match the levels when copying across projects because the intermediate processing function is highly restricted. You only have the choice to select the marked target object as the target (i.e., the objects are copied underneath this target object) or to completely reconstruct the hierarchy to be the same as it was in the source.

See also Application (Page 47)

6.3 Application Call: "Extra > Cross-Project Copy" menu

Procedure 1. Open the target project.

2. Drag&drop an object under which the copied objects are to be created into the "Target" field.

3. In the "Source" list, select a project containing the objects that are to be copied.

The project is displayed in the small Navigator at the bottom.

4. Use drag&drop to drag the required objects into the "Objects to be copied" area.

You cannot set the project as an object to be copied. In this case a complete project would be copied underneath another project, and this is technically impossible because projects cannot be hierarchically arranged.

5. If necessary, set the options using the "Extended" button. See also section Copying across projects: Extended (Page 73).

Copying across projects 6.3 Application


6. To start the copy process, click on the "Execute" button.

The window remains open. The copying operation can be repeated or a new target node can be set.

You can use the "Undo" button to remove all newly created objects and undo renaming operations.

7. Click on the "Save" button to save your changes.


Cross-class copying 77.1 General

Aim Cross-class copying is used to retain the relation between objects with different classes during copying. Within this context, the various "classes" are identical to the content of the "Units", "Locations", and "Documents" tabs.

When copying via drag&drop, you cannot retain the relation between objects with different classes, because it is not possible to select objects associated with different classes/tabs at the same time.

Behavior during cross-class copying You can use cross-class copying to select and copy objects from the "Units", "Locations", or "Documents" tabs at the same time. When you do this, the relation which exist between the objects in the copy set are retained.


Principle ● If you only select and copy objects from a tab during cross-class copying, then there is no

difference between using this function and copying via drag&drop.

● However, if objects associated with different classes/tabs are included in the copy set during cross-class copying, then the references that exist within this set will be copied along with it.

Restriction You cannot use the following objects as a source:

● Objects which are located under an object and which have already been selected for cross-class copying

● Document objects (DocObj)

● Attributes

● Connectors

In other words: You cannot use an attribute specifically as a source. However, please note that these exceptions only apply to the source object. In the case of all subordinate objects, these three object types are also copied.

Cross-class copying 7.2 Scope of copying


Deviations: ● Alias pointer

The object referenced by means of an alias pointer can never be included in the copy set. Reason: The alias branch is located directly underneath the project. Copying the project itself by means of cross-class copying is not permitted. Additionally, multiple selection is also not possible. This means that it is not possible to set up a copy set that contains both a device branch and the alias branch.

Handling references for objects that are brought over References in objects that are brought over are retained and bring over additional objects.

Evaluated collections ● "CDevice

OwnSpecifications

OwnElements

OwnDevSymbols

OwnConnectors

OwnDocuments

CLinks"

● "Device

OwnSpecifications"

● "Document

OwnSpecifications

Documents

DocObjs

Devices"

● "StandardTable

StandardValues"

● "Specification

OwnSpecifications"

● "StandardValue"

● "DevSymbols"

Cross-class copying 7.3 Use


7.3 Use

Procedure To copy across classes, proceed as follows:

1. To open the "Cross-class copy" tab, click the "Plugins > Basic > Cross-class copy" menu.

2. Drag the required copying target from the Navigator and drop it onto the "Destination" field on the open tab.

3. Drag the required objects from the Navigator one after the other and drop them onto the "Objects to be copied" field. If you select objects from different tabs, the relations between objects of different classes are retained.

4. Undoing a selection:

– To undo the selection of an object in the "Objects to be copied" field, select it with a right-click and then click the "Remove" command in the context menu.

– To undo the selection of all objects in the "Objects to be copied" field, right-click and then click the "Remove all" command in the context menu.

5. Click the "Execute" button to start the copy process.

– If you wish to undo the copy process, click the "Undo" button. The already in the Navigator displayed copied object will be removed in this case.

– If you wish to combine the "Execute" and "Save" commands as one operation, select the "Save automatically" option before clicking the "Execute" button.

6. Click the "Save" button.

Result You find the copied objects in the Navigator, under "@Copyref" on the "Units" tab. This refers to a Device without a base object pointer. References between copied objects are retained, even if the objects relate to different classes/tabs.

Cross-class copying 7.3 Use



The Object Matcher 8

Tasks of the Object Matcher: Comparing and copying

The Object Matcher compares two sub-trees in different projects. Differences (object only in the source, object only in the target, object differs in the source and the target) are always resolved in favor of the target. In other words: only the target project is changed, while the source project remains unchanged.


Minimum amount to be copied All copying functions in COMOS have a common minimum scope of copying (constituent parts 1., 2., and 4.): Everything that is not inherited or referenced is copied. See also section The copy amount (Page 19). Inherited information is recalculated on the basis of the new owner.

Extended object amount There are various items of information that must or should apply in the same way throughout the project for all users: standard tables, unit systems, and so on.

Since this information should apply throughout the project, it is appended in the information hierarchy directly underneath the project. It makes no difference whether you now name and display this information as a "table" or as an "object", the principle is always the same: a compendium of information that is to be applicable throughout the project. We could also be talking of containers.

In many of the dialog windows this information is displayed in the form of "tables". But unfortunately the terminology was never quite consistent: sometimes the term "standard tables" was used and at other times it was "selection lists". But please note that it is not necessary to display this as a table, it is simply more practical on some occasions.

All this information has one feature in common: it is managed by the administrator; normal users simply use this information without needing to know exactly where this information is located and how it is to be edited.

For that reason this information is not displayed in the Navigator.

This information is collected in the Object Matcher. In other words: the Object Matcher displays more than the Navigator does. Thus the display is selected as an object. But do not be confused by this: if something is also displayed as an object within the Object Matcher, then it is for example still exactly the same unit system that you perhaps edited a few minutes earlier as a "table".

The Object Matcher 8.2 Function mode


Handling of references in the Object Matcher Projection for referenced objects: A projection is conducted when copying structures. There is a similar mechanism in the Object Matcher, but as opposed to the Copy structure function this projection is not visible and also cannot be set again by using drag&drop.







Handling of references for subordinated objects References in objects that are brought over are retained and bring over additional objects.

When a report is copied into another project, the engineering objects that were placed on this report are always brought over. (Technically: DocObj.Reference is brought over.)

Specialties It is also permitted to view the project in the Object Matcher. Therewith the project can be copied. However, note that projects cannot be located under other projects. In other words: the copied project is not inserted into the target project, but instead the target project is overwritten.

8.2 Function mode The allocation and comparison of the objects is conducted from the start node onwards (including the start node itself and all objects located underneath it).

8.2.1 Color scheme The Object Matcher does not only have the most comprehensive filter function anywhere within COMOS. It can additionally compare the source and the target of the copy process beforehand and displays the differences in color in a structure tree.

The object´s colors mean:

Color Description Layer Red Object only exists in the target project (allocation level) Green Object only exists in the source project (allocation level) Yellow Objects differ (comparison level)



Color Description Layer Blue Object differences in the substructure (comparison level) Gray Objects are largely the same. (comparison level)

8.2.2 Allocation of objects ● The allocation as to whether two objects are to be compared is done on the basis of the

name.

● For engineering objects the class is also considered.

● If a name differs, the hierarchically subordinated objects are no longer allocated.

● Allocation of objects is conducted by name

8.2.3 Comparison of objects

What does "same" mean? Within COMOS, objects are uniquely differentiated by means of the UID. In other words: In COMOS two objects that are identical in terms of their properties, collections, and links, can nonetheless not simply be exchanged. The UID turns each object into a unique and unmistakable object, just as a genetic fingerprint of a human being.

The Object matcher consider the UID, otherwise objects would always be regarded as being different.

Often you can tell immediately why two objects are flagged as "different". Sometimes the reason for the difference may be more concealed. The following explains all situations that lead to differences.

Comparison of the properties: Properties always contain a single item of information and only relate to the object itself. Each property has a data type.

An example for such a property is the label that is input for an object. The data type is thus a string. Such a string can be easily compared and each difference leads to two objects being flagged as "different". This also corresponds to the intuitive understanding of the user: if the labels for two allocated objects differ, then the objects are also need to be flagged as "different".

But the settings for options and switches are also saved and compared as properties. As a rule the data type here is Boolean (yes/no). If the "Request" option is activated for a base object and not for the allocated second object, then both objects are flagged as "different".

In addition, there are properties that serve for order, sorting or functional labeling. An example of this is the status. This information is saved as data type Long. If different status information had been input for engineering objects (the first object is "open" and the second is probably "closed"), then both objects are flagged as "different".



The last group of properties that need to be mentioned are the pointers (= references), for example, a unit pointer or a location pointer. These pointers are of data type "Object" and therefore cannot be directly compared with one another in a meaningful way.

Helpfully, the FullName of the referenced object is queried from the source and the FullName is also determined from the referenced object in the target. The FullName is a string, which means that two strings are now available and these can be compared.

Please note: the name of an object is only a part of the FullName! For this reason references can also be labeled as being different even if the names themselves are identical.

Recommendation: the names of the source node and the target node should be the same, otherwise a reference that is pointing outwards cannot be allocated meaningfully. The project itself is excepted from this; this should in any case be different.

Comparison of the collections There are different types in the case of collections as well. Basically there are:

● Collections that are regarded as "belonging to the object"

Examples for the engineering object: Attributes or connectors. This information is displayed in the lower window area when the object is marked above.

● Collections that are handled as a collection of "independent objects"

Examples for the engineering object: elements, documents. These objects are displayed in the structure tree in the upper window area.

The collection of attributes is taken as an example from the first group, "collections belonging to the object". Objects are flagged as "different" in the collection if:

● Tn attribute is renamed.

● The content of an attribute is changed (Value or OwnValue).

● The data type of an attribute is changed.

This case can partially not be recognized at first glance! A "zero" can be entered either as a number or as a character; in both cases only "0" is seen, but the attribute is differs!

● The position of the attribute on the tab is moved.

● An attribute is deleted or added.

● As well as the other properties.

The objects of the second group – collections of "independent objects" – are displayed in the upper window area and are completely compared again. In other words: if a difference is found in an object of this collection based on the above rule, then the "parent object" of the collection is flagged as having a "difference in the substructure".



8.2.4 Summary of the most important points

Important rules concerning object mapping The allocation of objects is done by means of the name per level. If a name is changed, one object is flagged as being "only in source project" and the other one is flagged as being "only in target project".

In other words: the inner relationship of the objects is lost. (If you require an absolute allocation of objects, for example, with distributed databases, you then have to resort to the "synchronize databases" function. You find additional information on this topic in the "COMOS Administration" manual, keyword "Creating the synchronized copy (ExportDB)". Allocation through the name is not resistant to moving, meaning that: when an object is moved to another level, no allocation is done any longer (in each case relative to the start node).

Colors: red and green

Important rules concerning object comparison and matching Properties are compared precisely, with the exception of pointers (see the next section). In other words: even if just one single property changes, the object is flagged as being "different". Color: Yellow

Pointers or references (special type of a property) are compared through the FullName of the referenced object. Moving has the effect that the FullName of the pointer changes, thus a property of the two comparison objects differs objects and the objects are flagged as being "different" in the Object Matcher. Color: Yellow

Collections that are regarded as belonging to the object are compared completely. In other words: if a characteristic in such a collection changes even minimally, the object is flagged as being "different". Color: Yellow

Collections that are treated as a collection of independent objects are evaluated in two stages:

● In relation to the "parent object" of the collection: if a member of the collection is renamed, the collection is made enlarged or reduced, the "parent object" is flagged as having a "difference in the substructure". Color: Blue

● The objects of the collection appear in the structure tree in the upper window area and are compared completely. Here the mechanism begins again. Color: yellow, blue or gray, depending on the difference from the target object

8.2.5 Documents special case In the case of reports the contents are only partially matched: only the information that has an effect in the object model. Graphic elements (lines, circles) are only stored in the crp file and are not taken into consideration when comparing two objects.

Please note: Documents, by mean of theDocObjs own information which objects are placed. How DocObjs of this type are handled during the copying operation primarily depends on the mode.

The Object Matcher 8.3 Application


However, the effect of the mode only applies when copying is actually done. In other words: an amount of data can be flagged as being the same in the Object Matcher, but small differences may appear nonetheless after the copying operation, depending on the mode of the DocObj.

8.3 Application

8.3.1 Comparing objects from different projects 1. Select the source project and the target project in the corresponding lists.

2. Click on the "Set target and source project in tree" button.

Both projects are displayed on the left in the Navigators.

3. Set the start node

Once the projects have been set, the two lists are replaced with the "Source node" and "Target node" fields.

4. Use drag&drop to drag a start node from the upper Navigator into the "Source node" field and a target node from the lower Navigator into the "Target node" field.

You can also drag an object from the main Navigator into the applicable field or a standard table from the "Standard tables" window. Depending on which project is currently open, you can specify the source node or the target node. If necessary, change the project.

Once the start node and the target node have been set, the two buttons "Start object comparison" and "Filter settings for object match" also turn active.

5. Click on the "Filter settings for object match" button.

In the filter settings you specify which objects will be compared. In the Object Matcher, objects are displayed that are not visible in the main Navigator. In the filter settings you can stipulate what is not to be compared and hence also not displayed.

The classes for the "engineering object" object are displayed on the left-hand side.

The system types are displayed on the left-hand side. The following list explains a number of important system types:

Table 8- 1 Objects in the filter settings

Object (system type) Icon Comment Engineering objects This includes all engineering object classes. Objects on the left-hand

side of the filter settings. If system type "Engineering objects" is switched on, then all classes on the left are automatically deactivated.

Base objects The term "base object" is here strictly used and only stands for the "CDevice" system type.



Object (system type) Icon Comment Documents (links) This class of an object only makes sense if base data are compared,

since this class carries the attributes for documents there. This class cannot be used in a meaningful way with engineering objects. Do not confuse this with the system type Document of an engineering object (displayed on the right-hand side), which are the actual documents.

Standard tables

Suppliers/ manufacturers

Unit groups

Run cases

Languages

Parameters

Document types

Located directly under the project; not displayed in the main Navigator and the two Navigators to the left in the Object matcher. This means that this object is exclusively displayed in the "results of the object comparison" area.

Start comparison Click on the "Start object comparison" button.

The comparison result is displayed on the right in the upper and lower windows. The following is displayed in the lower window:

● For all objects: own attributes

● For all objects: own connectors

● DocObjs

● Values of the standard tables (Standardvalues)

● Standard values: Symbols for engineering objects (DevSymbols)

● Base objects: own symbols (OwnDevSymbols)

● Base objects: own suppliers (OwnSuppliers)

Objects that only exist in the source object or target object are displayed without any further functionalities in a list row.

Objects that exist in both branches but differ are identified as such with the help of an icon at the start of the row. If attributes or connectors are involved, you can open the additional "Object differences" detail window by double-clicking.

This window lists all the changed properties as well as the changed graphical properties. White arrows stand for a checked in property, and black arrows for an inherited one.

To see the display details for another object, leave the detail window open and double-click on the other object. The contents are swapped in the open detail window.



Editing data: matching Where differences occur (object only in the source, object only in the target, object differs in the source and the target), only the target project is changed.

You have two options:

● Edit the differences individually

● Perform global matching for the entire amount of data being checked

8.3.2 Comparing objects from the same project If you activate the "Object comparison within a project" option (at the top in the Object Matcher), you can compare objects from one and the same project.

The interface is slightly modified:

● The Navigator trees and the "Set target and source project" icon are missing.

● The "Source node" and "Target node" text fields (they function in the same way as a comparison of the objects between two projects) can be viewed directly instead of the "Source and target project" lists.

● New: A list with the SourceSystemFullName and DestinationSystemFullName columns. They incorporate or exclude references in the comparison (= reference display).

Apart from the option to determine how references are handled in a comparison, the project-internal object comparison functions in the same ways as an object comparison between two projects.

Include / exclude references (reference display) When objects are compared within a project, there is the option to control the processing of references. For example, a reference can be a location pointer. In practice it often happens that various references have no relevant differences when comparing two objects.

Example Unit 1 has a location pointer to Location 1. Unit 2 has a location pointer to Location 2. If you were to compare unit 1 and unit 2, then all objects would be marked as "different".

In such a case you can map the location pointer (the reference) "Location 1" to the location pointer (the reference) "Location 2". This means: location pointers "Location 1" and "Location 2" are treated as identical.

The Object Matcher 8.4 Context menu


Application: The text "Location 1" is input in the "SourceSystemFullName" field.

The text "Location 2" is input in "DestinationSystemFullName" field.

Note

Please note that this involves purely textual input. The location pointers are not actually compared, but instead all pointers with this name are compared. Thus if there are also other pointers with the same name then they will likewise be ignored when comparing the objects.

Example There is a location pointer to a location called "Chemical1". At the same time there is a unit pointer to a unit called "Chemical1". This is possible because the names are only guaranteed to be unique on each tab. In that case both pointers are not taken into consideration.

Excluding references (pointers) completely: If you input a " *" or a "*" in the DestinationSystemFullName field, then these pointers are not considered at all.

Note

Note that this type of comparison is only intended for display, and it cannot be used to actually compare.

8.4 Context menu The context menus reconcile the differences individually. The context menus are called by right-clicking, whereby only that subset of commands is visible that is also meaningful for this object.

Command Description Structural differences > Delete objects in target project

The information of the source project is taken over for the marked object and all objects underneath it. In doing so, all objects that only exist within the target project in this sub-branch are deleted.

Structural differences > Retain objects in target project

The information of the source project is taken over for the marked object and all objects underneath it. In doing so, all objects that only exist within the target project in this sub-branch are retained.

Take over object difference into the target project

Takes over the information of the source object for the marked object.

Take over object into the target project

Copies the object from the source project into the target project.

The Object Matcher 8.4 Context menu


Command Description Delete object in the target project Deletes the object in the target project. Navigate to the next object difference

Navigates to the next object that is new, was deleted, or differs. If possible, the object is also displayed in one or both Navigators of the Object Matcher. This is especially helpful if a difference in the substructure is displayed for an object.

Compare again The data can also be edited within the Object Matcher in order to remove any differences. New objects could be produced in the target project as a result of this editing of the data and hence also differences could arise that had not existed at the time of the first comparison. The two databases to be matched can be processed in an iterative manner until there are no more differences. This context menu is identical to what you would see if you pressed the "Start object comparison" button.

Click on the "Match" button for an automatic overall comparison (matching):

In the "Match" window, choose whether objects that only exist in the target project are to be deleted.


Delete 9

A user can only delete objects if he or she has the right to delete. Different aspects need to be taken into consideration, depending on which object is to be deleted and in which way.

9.1 Deleting objects via the user interface

9.1.1 Overview In COMOS there are the following methods with which objects can be deleted via the interface:

● regarding general context-sensitive menu

The general context menu is offered in COMOS at various points: In the Navigator, in the windows, in the properties, etc. Depending on the context, it contains different submenus.

If you are working with a cell-oriented list, such as a query for engineering objects, for example, the object of the marked cell is deleted. If you are working with a row-oriented list, the row is selected as a whole and, consequently, the row object is deleted.

● Via the "Edit > Delete" menu

This menu deletes the object that was selected in the Navigator.

● Via the Delete key

Select a base object or engineering object from within the Navigator and press the [Del] key on your keyboard.

● Via deletion icons, such as in the properties of an engineering object next to the unit pointer.

Following applies to all deletion methods: If a reference is marked, it is then deleted, but the object itself and all the other references to this object are retained. If an engineering object was deleted, the marked object and all the references to the object are deleted, but the associated base object still exists. If a base object was deleted, the engineering objects derived from it are still retained.

A safety prompt is displayed before the objects are deleted: A window opens in which the user must confirm that the objects that have been selected should actually be deleted.

Delete 9.1 Deleting objects via the user interface


9.1.2 Checklist when deleting If there are any exceptions or unclear points when attempting to delete objects via the interface, the "Delete check list" window is opened.

It individually displays the warnings and error messages for all objects for which there are exceptions or unclear points.

Example Create a new object in the engineering project under a base object of the base project. Command: "New > New base object in engineering project".

If you try to delete the owner in the base project, the above-mentioned window opens.

● Warnings:

Warnings only appear if you are working via the COMOS interfaces.

Warnings are output both for "normal" users and the administrator.

However, the administrator only receives warnings, since he or she can always delete (with one exception). Thus an action that would result in an error message for a user would "only" result in a warning for the administrator.

Warnings occur, e.g.:

– In connection with notes on objects placed on reports.

– In the case of objects with working areas for which the user has no authorization.

– If the DeleteWarning script block is set.

● Error messages / administrator warnings:

If an error message is issued, then the object is not deleted under any circumstances.

Abort messages and administrator warnings occur:

– In connection with missing rights.

– In the case of locked objects.

Administrators are permitted to delete, but get an administrator warning.

– If the CheckDelete script block is set.

Prevents normal users from deleting. Administrators are permitted to delete, but get an administrator warning.

– In the case of signed objects

Planning data that contains signatures cannot be deleted by "normal" users. Of course, this also applies if entire branches are to be deleted: if there is an object with a signature in one of the deeper branches, then this object and its owners are not deleted. Administrators are permitted to delete, but get an administrator warning.

– In the case of objects from other projects.

Abort also for administrators. See the above example with the local base project.

Delete 9.2 Deleting without the COMOS interface


Application The information as to on which document the object was placed appears in the Context object column.

All objects are deleted from the list, and not only the ones that were selected.

9.2 Deleting without the COMOS interface Objects can also be deleted without the COMOS interface by means of scripts. Scripts can be incorporated in COMOS at various points, for example, via the "Script" tab of a base object, in queries or standard import operations.

As opposed to deletion via the interface, neither safety prompts nor warnings are given in such a case. The objects are deleted directly.

If it is not permissible to delete the objects, then this will be prevented in all cases. However, the users / administrator are not conveniently informed via the "Delete Checklist" but instead by core messages.

9.3 Deleting in working layers and in the history management From a technical point of view, it is differentiated between logical deletion (= soft deleted) and physical deletion (= hard deleted).

This distinction is relevant if you are using working layers or the history management.

Soft deleted / logical deletion The object is marked as "deleted" (= Delete Flag set). The object cannot be used any longer and is hidden in the default display of the Navigator. However, it still exists physically. In the "Working layer display" and "History display", objects that have been soft-deleted are marked with a red text but still remain visible in all the interfaces (such as the Navigator, queries, etc.).

Hard deleted / physical deletion The object is actually deleted from the COMOS database.

Delete 9.4 Deleting documents


9.4 Deleting documents

9.4.1 Deleting documents If you want to delete a document, mark it in the Navigator and proceed as described. See also section Auto-Hotspot.

If you delete the original document, then all the reference documents are deleted as well. If you delete a reference document, the original document and all other reference documents that point to the original document are retained.

9.4.2 Protecting documents against deletion In order to prevent a document from being deleted, you can lock it by using the "Locked" button in its properties. The document cannot be deleted any longer, except by the administrator, who receives a warning before actually deleting the document. The lock can only be removed and set by users who possess the "Lock object" object right. You find additional information on this topic in the "Rights" manual, keyword "Lock object function right".

9.4.3 Deletion in interactive reports There are two options when deleting in interactive reports:

● You can delete an object from the report, but without deleting the object itself. The object continues to be available in the Navigator and can be edited or placed on other diagrams.

Procedure: Select the object on the plan and then call "Delete" from the context menu.

Exception: If the object in the Navigator is located underneath the plan, not only the display on the plan but also the object itself is deleted.

● You remove an object from the report and from the Navigator. The object is deleted and is not available any longer.

Procedure: Select the object on the plan and choose "Delete" from the context menu. If you are working with working layers or history management, the object in the Navigator remains visible but can no longer be edited. See also section Deleting in working layers and in the history management (Page 65).

If you delete an object placed on an interactive report in the Navigator, the display on the plan is no longer linked to an object and thus becomes inconsistent.

Delete 9.4 Deleting documents


Inconsistent objects Inconsistencies are displayed in red in the interactive report. Use the "Inconsistency > Show previous" and "Inconsistency > Show next" context menu to navigate to all inconsistencies. If an inconsistency is selected, you can get information via "Inconsistency > Analyze inconsistency" as to why the object is inconsistent. You can delete all inconsistencies in the plan via "Inconsistency > Delete all inconsistent objects".

Deleting the content of a diagram If you select an interactive report in the Navigator (the original document) and choose the "Delete content" command from the context menu, then the entire content of the report is irrevocably deleted. This command is only available for the following drawing types:

● "Detail*" drawing types (i.e. all drawing types starting with "Detail")

● "SLine*" drawing types (i.e. all drawing types starting with "SLine")

The document object with its "Name", "Description" and "Template" properties and the revisions are retained. The graphical content and all information as to which objects had been placed on the report are deleted. The created objects are retained, but are no longer placed on the report.

Delete objects outside Talking of "objects", we are referring to report objects (RObjects). An electrical connection is also a report object, although the connection does not have an object in the Navigator. Drawing objects (free lines or circles) are also report objects.

This command deletes all report objects that are completely located outside the sheet area. The objects involved in the Navigator are retained.

Background and main area of application: Third party programs sometimes use a working area that protrudes beyond the actual sheet zone. Sometimes objects that have no actual importance and have only been placed there for personal reasons (for example, as a template) are deposited in this area.

COMOS can also manage objects that are located outside the sheet zone.

However, objects that are located outside the sheet area are greatly restricted in their functions in many cases or even supply incorrect results. For example, the details regarding the sheet path and zone are either incorrect or missing.

If you forgot to delete the superfluous objects located outside the sheet area while carrying out an import operation, you can then clean up the report with this mouse command

9.4.4 Reference documents and document groups

Deleting reference documents of a document group Via the the project properties you set whether all reference documents are to be deleted automatically when deleting the original document: "Options > Documents" tab, "General" control group, select "Delete reference documents as well" option.

Delete 9.5 Deleting in the Object Browser


If this option is deactivated, any reference documents that point nowhere can be deleted from the document group by using the "Delete references without original" command.

If the unit pointer or the location pointer of a document group is changed, it is possible that some of the reference documents now point to documents that do not belong to the new unit/location. With the "Change of unit/location/name" control group in the "System information" tab of a document group, you can specify that all reference documents are to be checked automatically if the pointers are changed and invalid ones are to be deleted.

9.5 Deleting in the Object Browser The Object Browser displays the results of a query in the form of a table. It appears at many different places within COMOS, for example, when selecting a project, in bulk processing, and at all other points that are based on a query. You find additional information on this topic in the "Queries" manual, keyword "Object Browser".

If the query was configured correspondingly, it is possible to edit the contents of the Object Browser: You can include new columns in the display, delete columns that are displayed and edit values in cells - and also delete them.

9.5.1 Deleting columns In the context menu of a column header you can remove a column from the Object Browser using the "Delete" command. All that happens is that the display in the Object Browser is changed. Deletion of the column does not change any of the objects nor their properties.

9.5.2 Delete rows Each row in the Object Browser is based on an evaluated object, the so-called row object. The singlel cells of a row contain the evaluated properties of the row object or other objects that have a relationship with the row object (e.g., its owner object).

If the column in which a cell is located is editable, you can delete the value of the cell. You find additional information on this topic in the "Queries" manual, keyword "Editing cells directly".

Row-oriented query:

Regardless of which object is marked in the row: The "Delete" command in the context menu always deletes the row object. Also called list query. You can find additional information on this topic in the "Queries" manual, keyword "Query as a list".

Cell-oriented query

If you mark a cell that points to another object than the row object and then select the "Delete" command from the context menu, then the marked object is deleted.

Delete 9.6 Miscellaneous


Regardless of which of the two query types is involved, the following applies:

● You want to delete the value of a cell that does not point to another object, but which instead reads the text of the description, for example:

Set the mouse cursor into the cell and delete the contents via the keyboard. If you wish to delete the values of several cells of the same column, select the desired cells and then call "Edit" from the context menu.

Wrong: You select the cell (blue background) and call the "Delete" context menu. This would delete the object that the property belongs to, namely, the row object.

● You want to delete a cell that points to an object:

The same restrictions apply as when deleting via the user interfaces.

Example:

It is not permissible to delete an object from another project. If you try to delete the base object of a row object, the "Delete" context menu will be grayed out as a result.

9.6 Miscellaneous

Deleting selected objects within 2D-Designer The "Properties" and "Navigation" commands are available for a selection involving main objects and subobjects. These commands are only carried out for the main objects. All other commands in the context menu are carried out for all objects in the selection.

Delete project A user can only delete a project if he owns the "Delete" right and the "Project management" metaright for this project at the project level.

Delete 9.6 Miscellaneous



User interface reference 1010.1 Object Matcher

Call: "Extra > Object Matcher"

The "Object Matcher" window has four areas:

Range Description Top left Navigator for the source project Top right Comparison list: Results of the Object Matcher Bottom left Navigator for the target project Detail display Detail display: Differences for the marked object

Buttons on the top edge:

Button Description "Set target and source project in tree"

Takes over the project from the "Source project" field into the upper Navigator and the project from the "Target project" field into the lower Navigator.

"Filter settings for object match" Takes over the project from the "Source project" field into the upper Navigator and the project from the "Target project" field into the lower Navigator. The filters affect which objects are allocated and compared. No data is changed yet.

"Start object comparison" The allocation and comparison of the objects is conducted. No data is changed yet.

"Navigate to the next object difference"

Navigates to the next object difference.

"Restart" Deletes all fields in the window.

"Display and evaluation including inherited objects" option COMOS knows different methods to transport information from one object to another, including the inheritance through references. A reference object itself cannot be edited but is only serves to collect information and to pass it to the original object.

User interface reference 10.1 Object Matcher


Example

Source:Without reference@1EA

Object A

Object B

Object C

SpecsA

SpecsA

SpecsB

SpecsC

Target:With reference@1EA

Object A

Object B

Object C

SpecsA

SpecsA

SpecsB

SpecsC

Object BSpecsC

SpecsC

Source:Without reference

Target:With reference

@1EA

Object ASpecsA

SpecsA

SpecsB

@1EA

Object A

Object B

Object C

SpecsA

SpecsA

SpecsB

SpecsCObject C

SpecsC

Object B

SpecsC

Object B

Option is activated Option is deactivated Object A on the left is flagged as "the same" as object A on the right.

Object A on the left is flagged as "the same" as object A on the right.

Object B on the left is flagged as "different" with regard to object B on the right.

Object B on the left is flagged as "the same" as object B on the right.

Object C on the left is flagged as "different" with regard to object C on the right.

Object C on the left is flagged as "different" with regard to object C on the right.

The difference between the two displays thus only effects object B.

Both displays are correct in themselves. Technically speaking, the change in data takes place at object C, which is also correctly flagged as "different" in both cases. The change at object B is "only" a consequence of the change at object C.

User interface reference 10.2 Copying across projects: Extended


As a rule, it thus makes sense to do as follows when carrying out data matching at object C: either take over or delete the reference at object C. Recommendation: the "with inherited objects" option should be deactivated.

However, object B also changes from the user point of view, since in one case it displays the attributes of object C and in the other case it does not. However, the display with inherited objects could lead to a problematic view: a user might get the idea of checking in and editing the inherited attributes at object B and thereby synchronize with the data at the other object B. This is not recommended because the cause is, as described above, to be found at object C.

Comparison list, detail display The upper right-hand dialog area of the Object matcher is the "results area": this is where objects that differ from the source node and the target node are listed .

The lower, right-hand dialog area of the Object matcher is the "detail display" where all differences from the above marked object are listed.

10.2 Copying across projects: Extended

"Options" control group Option Description "With document revisions" Document revisions are included in the amount to be

copied. "Save automatically" Once executed, a sequence is saved automatically. "DB based technique" This copying procedure is suitable for copying large

amounts of data because the copy process consumes less of the main memory. The procedure is not suitable for small amounts of data since the structure of the entire project is always analyzed. This option excludes all other options pertaining to this control group and only enables the "Ignore" option in the "References" control group.

"Include placed objects" Objects in a report are kept when the report is copied. When the new report is opened, the "Define paste mode for COMOS objects" window no longer opens.



"Paste" control group Option Description "Below target" The subarea from the source project is copied directly

underneath the target object. With this option, you can only copy objects which may be created under the target object.

"Create hierarchy" The structure is created in the target project just as it is in the source project, and the objects are created at the same location of the hierarchy as in the source project.

"References" control group Option Description "Collect" On the same layer as the copied object, a "@COPYREF"

object is created containing all the references of the object.

"Reproduce" All reference objects are reproduced in the relevant position, as in the original project.

"Ignore" During the copy process, all references that relate to planning data (P-references) are lost. These include the unit pointers and the location pointers. References to base data (S-references) are retained. These are the pointers to the base object, references to base lists, etc. In principle this loss of references always only relates to references pointing outwards.

"Rename" control group Control group Description "New name for:" field In this field, enter the new name of an object that you

have selected in the table below. Table Drag&drop objects here which belong to the amount to

be copied and are to be renamed.

When the copy process is triggered, a search is made for projection possibilities. Thus, if the name of an object in the extended amount to be copied is changed, then it is projected onto another object.

For this purpose, any object from the amount to be copied is dragged into the table. If the object in the table is marked, the old name can be overwritten. The object is projected with the new name.

If a unit has a location pointer, you can thus drag the location into the table and input a new name. However, you must already have the information as to which objects are referenced and what name the reference targets should have. This information is not displayed in the "Cross-project copy" window.

If a projection is not possible, the object is created with the new name.



"Newly created objects" control group This lists all objects that have been included in the amount to be copied because of an option selected in this window. The copied objects themselves are not listed.

