| |
Attribute Definitions |
| <<< Identifying Application Data | Chapters | Attributes >>> |
Attributes are used to supplement the Parasolid data structure by attaching additional data to Parasolid entities. The attribute definition has properties which define the attribute’s behaviour when the entity to which it is attached is involved in modeling operations, by setting the:
These properties determine the normal processing which Parasolid applies to the attributes, as described in Chapter 95, “Attributes”. However, the application can specify an alternative processing methodology using callback functions invoked according to the:
Attribute definitions are used to specify the behaviour of individual attributes. Each definition contains:
assembly, instance, body, region, shell, face, loop, edge, fin, vertex, lattice, surface, curve, point, group
|
Note: Attributes cannot be attached to orphan geometry regardless of the entity class. See Section 95.5.2, “Modeling operations and attributes attached to geometry”, for more information. |
See Section 95.1, “Introduction”, for more information.
Attribute fields can also be given names if you wish. See Section 94.2.1, “Using named fields”, for details.
Attribute definitions belong to the session, they are not associated with any partition. Once created, an attribute definition cannot be changed or deleted. In particular, attribute definitions are not deleted by rolling back the session to before they were created - they continue to exist.
|
Warning: Once created, you must never try to change an attribute definition. If you want to make changes to attribute definitions in your product, you should create a new attribute definition using a new string identifier for the name, and identify it as a “new” version of an existing attribute definition using any system you find convenient. See Section 94.2.3, “Attribute definition names”, for more information. |
Within a session, many different attribute definitions may be created provided that they all have distinct names.
There are two complementary ways of handling attribute fields in Parasolid.
Standard attribute definitions, created using PK_ATTDEF_create, contain fields whose contents must be accessed via the number of the field, as defined in the attribute definition.
To support the distribution of Parasolid models via a Web or text-based interface, you can also define attributes that contain named fields, using PK_ATTDEF_create_2. The contents of these fields can be accessed by using the field name, meaning that you do not have to rely on the order in which fields are defined in the attribute definition.
For information on accessing the contents of a specific field in an attribute, see Section 95.2.3, “Adding to and retrieving data from attribute fields”.
The following table summarises the functions that are specific to attribute definitions.
|
Return the standard form (PK_ATTDEF_sf_t) of an attribute definition for non-named fields. If called on an attribute definition created with PK_ATTDEF_create_2, this function returns the non-named standard form. |
|
|
Return the standard form (PK_ATTDEF_sf_2_t) of an attribute definition for named fields. If called on an attribute definition created with PK_ATTDEF_create, this function returns NULL for field names. |
|
|
Ask whether the given attribute definition is a group closing attribute definition. See Section 98.7, “Closed groups” for more information. |
|
|
Sets the given attribute definition to be a group closing one. See Section 98.7, “Closed groups” for more information. |
|
|
Ask whether a given entity may own an attribute of a given definition |
|
|
Return the number of user-defined attribute definitions in the session, optionally together with the attribute definitions themselves. |
It is recommended that all attribute definition names are prefixed with a string which relates to the application or company name. If your application automatically (and transparently) adds and removes this string as appropriate, it should never have to deal with an attribute definition on a part that is incompatible with those defined in the application.
For example, Parasolid’s system-defined attribute definitions are prefixed with “SDL/TY” to ensure they never clash with attribute definitions created by an application - the density attribute definition is called “SDL/TYSA_DENSITY”.
If two applications have an attribute definition simply called ‘Density’, but one uses an integer field and the other a double field, then the definitions are incompatible. A part created in one application fails to load into the other. The attribute definition should be given a name with a prefix specific to the application, thus avoiding conflict with attribute definitions in any other applications.
See Section 94.4, “System attribute definitions”, for a list of the other attribute definitions created by Parasolid.
If a given attribute definition actually represents a “new” version of an existing attribute definition in your application, then you can indicate this in the name of the attribute definition itself, if you wish.
Two attribute definitions are compatible, that is they can inhabit the same session, when they have:
When a part is saved, all attributes attached to entities in the part, and their definitions, are saved with the part; unused attribute definitions are not saved.
When saving a part in a format used by a previous version of Parasolid, attributes are removed from an entity if they are not supported for that entity type in that version of Parasolid. For example, saving a part in Parasolid V11.0 or earlier format removes any attributes attached to fins.
When receiving a part file, parts can only be loaded successfully if their attribute definitions are compatible with the attribute definitions in the current Parasolid session. The attribute definitions of attributes attached to entities in successfully loaded parts are created automatically.
Parts are not loaded successfully if their attribute definitions are incompatible with the definitions in the current Parasolid session. This means, for example, that two applications with incompatible ‘Density’ definitions cannot share any part with a Density attribute attached - the part fails to load.
All attribute definitions have a class which defines:
The modeling operations are explained in Chapter 95, “Attributes”.
|
Attribute is dependent on the size of entity but is independent of its position |
||
|
Attribute is dependent on both the size and position of the entity |
||
|
Attribute that transforms with the owning entity (for rigid body transforms), but is otherwise independent of the size and shape of the entity. See Section 14.2.9, “Assembly” for a description of rigid body transforms. |
start point or direction of movement of the tool that cuts a face |
|
|
Attribute that transforms with the entity providing that the entity is not changed in other ways |
||
|
As for class 1, attribute is independent of physical size and position for the entity to which it is attached. However this class of attribute supports multiple values - one entity may have multiple attributes with the same definition attached. |
||
|
As for class 4, attribute transforms with its owner (for rigid body transforms), but is otherwise independent of size and shape of the owner. However this class supports multiple values - an entity may have multiple attributes with the same definition attached. |
||
|
Attribute is created for internal use by Parasolid only. You cannot create definitions of this class, or attributes of any existing attribution definitions. There are no visible fields for attribute definitions of this class. |
||
Geometric entities may only be specified as the legal owner of attributes of classes 1, 4, 6, and 7. See Section 95.5.2, “Modeling operations and attributes attached to geometry”, for more information.
Callback functions provide applications with a more powerful method of attribute processing than Parasolid’s normal attribute handling. The functions are attached to attribute definitions, and are called by Parasolid when entities with that type of attribute undergo one of the following events:
Callback functions must be registered before they can be invoked. PK_ATTDEF_register_cb registers pointers to the callback functions supplied in your application, and PK_ATTDEF_ask_callbacks returns those pointers.
|
Note: Where an entity has multiple attributes of different definitions, applications should not rely on those attributes being processed in any specific ordering. |
There are two types of callback function:
These functions can modify and enquire about the attributes or other parts of a model as necessary. When a normal callback is invoked, the action it carries out replaces Parasolid’s normal attribute processing.
These functions cannot modify the attributes or other parts of a model in any way. After a call to a read-only callback returns, Parasolid processes the attributes according to their class, in the usual way.
You use the
callback_type
field in the options structure for PK_ATTDEF_register_cb to specify whether a callback function is normal (PK_ATTDEF_callback_normal_c) or read-only (PK_ATTDEF_callback_read_only_c)
Every attribute definition can have several callback functions associated with it: one for each type of event. Different events can then trigger calls to different associated callback functions. Each attribute definition has a set of logical flags that determine whether or not a callback function is called when an event takes place.
PK_ATTDEF_set_callback_flags sets these callback function on/off flags, and they are returned by PK_ATTDEF_ask_callback_flags.
For an example of this functionality, see the code example in the
C++\Code Examples\Application
Support\Attribute
Processing\Callbacks
folder, located in
example_applications
in your Parasolid installation folder.
|
Warning: If, at any time in a Parasolid session, you have registered any normal callback functions, tag persistence behaviour will be permanently disabled for the remainder of that Parasolid session. This will apply for all modeling operations that can split an entity and then delete one of the split entities. This affects a range of operations, including booleans, imprinting, blending and local operations. For more information about tags and tag persistence see, Section 2.4.2, “Tags”. Users and creators of Third Party Toolkits which might share a Parasolid session should carefully consider the impact of registering normal callbacks, as this will disable tag persistence for all parties. If you are registering read-only attribute callbacks, tag persistence is not disabled. If your application callback is read-only, then it is recommended that you register it as such. |
When an event occurs, a callback function is called once (only) for each attribute definition that has a callback for that event registered, and for which the participating entities have at least one attribute of that type attached.
Callback functions are called on bodies, regions, shells, faces, loops, edges, fins, vertices, geometry, transforms, groups, assemblies and instances. All events can occur to all types of entity, except that geometry, transforms, assemblies and instances are never merged or split.
The specific actions that are performed when an event occurs depend on the type of callback that is registered to the attribute definition for that event:
The existing behaviour is described in Chapter 95, “Attributes”.
|
Note: Applications should not rely on the precise sequence or number of events during a modeling operation remaining the same in future releases of Parasolid. |
If a normal callback function is invoked, normal Parasolid attribute processing does not take place, apart from necessary actions (namely, deleting attributes from entities which are about to be deleted). If this processing (as described in Chapter 95, “Attributes”) is required, then you must include it in the definition of the normal callback function.
Normal callback functions may call read-only Parasolid functions, and may create, modify, and delete attributes. Read-only callback functions can only call read-only Parasolid functions, and may not create, modify, or delete attributes.
Callback functions are given one or more arrays of attributes. These always have the attribute definition to which the callback function is associated.
Callback functions and flags are not transmitted by PK_PART_transmit or PK_PARTITION_transmit.
The callbacks are invoked as follows. In each case, the list(s) of attributes passed by Parasolid only contains attributes with the relevant attribute definition.
The interfaces to these functions are defined in Appendix G, “Attribute Callback Functions”, of the Parasolid Downward Interfaces manual.
There are some attribute definitions created internally by Parasolid, which have names beginning with the string “SDL/TY”. These attributes can be manipulated in the same ways as attributes with the application’s definitions.
The following definitions are provided for use by the application to attach attributes which can then be used by the application, and by various Parasolid functions:
|
Behaviour of empty groups when owning parts are split or merged |
|
See Appendix A, “System Attribute Definitions”, for more information on the attribute definitions created by Parasolid.
| <<< Identifying Application Data | Chapters | Attributes >>> |