Inheriting, Copying, Deleting COMOS. Platform Inheriting, Copying, Deleting. Trademarks 1. Inheritance. Copying: General Definitions 3

Transcription

1 Trademarks 1 Inheritance 2 COMOS Platform Operating Manual 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 04/2012 A5E

2 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 NÜRNBERG GERMANY A5E P 04/2012 Technical data subject to change Copyright Siemens AG All rights reserved

3 Table of contents 1 Trademarks Inheritance Definition of the single methods Digression: Inheritance for engineering objects Definition: Hierarchical inheritance Definition: Referencing Definition: Linking Definition: Inheriting via the Catalog tab Application Hierarchical inheritance Setting a reference (link) Setting links Inheriting via catalog attributes Check in object Copying: General Definitions Copying on a report The constituent parts of an object The copy amount References Allocation of objects Definition and classification Special reference types Alternative solutions Extended copy amount Comparison of copying methods Other sections for copying Copying the system project Copying with the Navigator Within the project Functional scope Application Copying with project switch Functional scope Application Copy structure Scope of copying Application...40 Operating Manual, 04/2012, A5E

4 Table of contents Required rights Preparing the copy operation Editing Concluding the copy operation Special cases regarding Projections / Projection prohibitions Copying across projects General Scope of copying Application Cross-class copying General Scope of copying Use The Object Matcher Scope of copying Function mode Color scheme Allocation of objects Comparison of objects Summary of the most important points Documents special case Application Comparing objects from different projects Comparing objects from the same project Context menu Delete Deleting objects via the user interface Overview Checklist when deleting Deleting without the COMOS interface Deleting in working layers and in the history management Deleting documents Deleting documents Protecting documents against deletion Deletion in interactive reports Reference documents and document groups Deleting in the Object Browser Deleting columns Delete rows Miscellaneous User interface reference Operating Manual, 04/2012, A5E

5 Table of contents 10.1 Object Matcher Copying across projects: Extended...73 Operating Manual, 04/2012, A5E

6 Table of contents 6 Operating Manual, 04/2012, A5E

7 Trademarks 1 Trademarks Registered trademark: COMOS Operating Manual, 04/2012, A5E

8 Trademarks 8 Operating Manual, 04/2012, A5E

9 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 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. Operating Manual, 04/2012, A5E

10 Inheritance 2.1 Definition of the single methods 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). 10 Operating Manual, 04/2012, A5E

11 Inheritance 2.1 Definition of the single methods 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 counterproductive 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." Operating Manual, 04/2012, A5E

12 Inheritance 2.1 Definition of the single methods 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. 12 Operating Manual, 04/2012, A5E

13 Inheritance 2.1 Definition of the single methods 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" 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. Operating Manual, 04/2012, A5E

14 Inheritance 2.1 Definition of the single methods 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). 14 Operating Manual, 04/2012, A5E

15 Inheritance 2.2 Application 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 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) 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. Operating Manual, 04/2012, A5E

16 Inheritance 2.2 Application 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 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. 16 Operating Manual, 04/2012, A5E

17 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. Operating Manual, 04/2012, A5E

18 Inheritance 2.3 Check in object 18 Operating Manual, 04/2012, A5E

19 Copying: General Definitions 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. Operating Manual, 04/2012, A5E

20 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. 20 Operating Manual, 04/2012, A5E

21 Copying: General Definitions 3.4 References 3.4 References The individual copying methods primarily differ through their handling of references 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. Operating Manual, 04/2012, A5E

22 Copying: General Definitions 3.4 References 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: 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. 22 Operating Manual, 04/2012, A5E

23 Copying: General Definitions 3.4 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. Operating Manual, 04/2012, A5E

24 Copying: General Definitions 3.4 References 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 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. 24 Operating Manual, 04/2012, A5E

25 Copying: General Definitions 3.4 References 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 All objects Base objects (CDevice) Documents Collections Attributes Attributes OwnElements OwnDevSymbols OwnSuppliers OwnConnectors OwnDocuments Attributes Documents DocObjects Devices Operating Manual, 04/2012, A5E

26 Copying: General Definitions 3.4 References System type Standard table Standard value Collections Standard values 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 26 Operating Manual, 04/2012, A5E

27 Copying: General Definitions 3.4 References 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 Operating Manual, 04/2012, A5E

28 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. 28 Operating Manual, 04/2012, A5E

29 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 X Extended object amount: connector tracking, some X Some objects are not permitted as root X Extended object amount: Lists, tables, unit systems: dialog windows BackPointer collections Base object pointers(s-references) (X) Base object pointer is X (otherwise created) X (otherwise created) X (otherwise created) searched for. The copying operation is blocked if the pointer to this precise object cannot be retained. Connection reference - X X X Alias pointer - X X X Engineering object references - X X X (S-references) References in the case of objects that have been brought over Project not changed: is retained Project changed: is lost There are no objects that have been brought over. 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) P-references are lost. S-references are retained 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 Are retained and bring additional objects over. Create hierarchy - X X X DocObjs X X X X DocObj depending on mode. "DocObj depending on mode." "DocObj depending on mode." Multiple selection - X - - Only apparently! Quick X - X - Manual intermediate editing - X (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 Are retained and bring additional objects over. DocObj depending on mode. -> Effect on "sameness" of data after the copying! Operating Manual, 04/2012, A5E

30 Copying: General Definitions 3.7 Other sections for copying Rights query at the target Simple copying Copy structure Copying across projects (X) X X Create All rights are required; All rights are required; but not necessarily Admin but not necessarily Admin Special points Revisions are deleted. Dialog window remains open Object Matcher X All rights are required; but not necessarily Admin Dialog window remains open both allocation and object matching 3.7 Other sections for copying 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". 30 Operating Manual, 04/2012, A5E

31 Copying with the Navigator Within the project 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. Operating Manual, 04/2012, A5E

32 Copying with the Navigator 4.1 Within the project 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. 32 Operating Manual, 04/2012, A5E

33 Copying with the Navigator 4.1 Within the project 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 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. Operating Manual, 04/2012, A5E

34 Copying with the Navigator 4.2 Copying with project switch 4.2 Copying with project switch 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 Engineering object references 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. 34 Operating Manual, 04/2012, A5E

35 Copying with the Navigator 4.2 Copying with project switch 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). Operating Manual, 04/2012, A5E

36 Copying with the Navigator 4.2 Copying with project switch Other This procedure is not identical with "copying across projects"! It is not possible to copy across databases 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. 36 Operating Manual, 04/2012, A5E

37 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. Operating Manual, 04/2012, A5E