 |
Attribute Definitions |
Attribute Definitions
| <<< Groups | Chapters | Attributes >>> |
These properties determine the normal processing which Parasolid applies to the attributes, as described in Chapter 47, "Attributes". However, the application can specify an alternative processing methodology using callback functions invoked according to:
Attribute definitions are used to specify the behavior of individual attributes. Each definition contains:
body edge point region fin group shell vertex transform face surface assembly loop curve instance
Attribute fields can also be given names if you wish. See Section 46.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.
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 such as eXT, 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 47.2.1, "Attribute processing".
The following table summaries the functions that are specific to attribute definitions.
| Function | Description |
|---|---|
|
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. |
|
It is recommended that all attribute definition names are prefixed with a string which relates to the application or company name. If the 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 the "System attribute definitions" section at the end of this chapter for a list of the other attribute definitions created by Parasolid.
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 47, "Attributes".
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.
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.
|
Warning: If you have registered normal callback functions, then tag persistence behavior is disabled for any single modeling operation that can split a face and then delete one of the faces. This affects a range of operations, including booleans, imprinting, blending, and local ops. Tag persistence is disabled because it relies on internal behavior incompatible with the use of callbacks. See Section 2.2.2, "Tags", for information about tags and tag persistence. If you are registering only read-only attribute callbacks, tag persistence is not disabled. |
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 behavior is described in Chapter 47, "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 47, "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.
| Callback type | When function is called | Data passed to the function |
|---|---|---|
| Split | ||
| Merge | ||
| Delete | ||
| Copy | ||
| Transmit | ||
| Receive |
The interfaces to these functions are defined in Appendix F, "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:
SDL/TYSA_DENSITY SDL/TYSA_HATCHING SDL/TYSA_REGION_DENSITY SDL/TYSA_PLANAR_HATCH SDL/TYSA_FACE_DENSITY
SDL/TYSA_RADIAL_HATCH SDL/TYSA_EDGE_DENSITY
SDL/TYSA_PARAM_HATCH SDL/TYSA_VERTEX_DENSITY
SDL/TYSA_REGION
See Appendix A, "System Attribute Definitions", for more information on the attribute definitions created by Parasolid.
| <<< Groups | Chapters | Attributes >>> |