The NX Object Model
NX models its objects in a variety of ways, depending on the purpose of the object and its relationship with other objects. The objects may be design-oriented (such as a hole feature), drafting-oriented (such as a dimension), analysis-oriented (such as a node), or manufacturing-oriented (such as a tool path.) This chapter defines some of the concepts surrounding the NX object model to aid developers in accessing and modifying objects embedded within NX part files.
Every NX object is referenced via a tag (the term entity identifier - or EID - is an older term for what is, essentially, the same thing as a tag). The actual physical representation of a tag is that of an unsigned integer. Tags are defined via a "C" typedef as tag_t in the header file uf_defs.h. Tags are really just identifiers that uniquely identify each object when it is loaded into memory from an NX part file on disk.
There is a special value for a tag that is never assigned to an NX object: NULL_TAG. NULL_TAG is defined in the header file uf_defs.h. Although NULL_TAG is currently defined as zero, you should not assume that zero and NULL_TAG are equivalent. You should always use the NULL_TAG symbolic constant in your code. NULL_TAG is useful for many purposes. Among them are the following:
to verify the creation of a valid object. By convention, routines that create objects return the tag of the newly created object. If the creation fails for some reason (e.g. improper input arguments), then the NULL_TAG is returned.
to signal the beginning and end of the cycling process (see below.)
Each loaded object has its own unique tag within an NX session. However, the tag given to an object is not persistent across multiple sessions of NX nor is it persistent across multiple uses of the same part within the same session. Furthermore, tags can be (and are) reused within an individual NX session. For example, if a piece of geometry is created and subsequently deleted, the tag that formerly identified the original piece of geometry can be assigned to a new piece of geometry at a later point in the same session. Also, if a part is closed within a session, the tags that were formerly associated with the closed part can be reused with the remaining parts in the session or with any parts that are subsequently loaded into the session.
The important thing to understand is that while the tag for the object may have a different value between sessions - or within a session if a part is closed and reloaded - the object associated with the tag is persistent.
Classes of Objects
All NX objects are referenced through their unique identifier (i.e. tag.) These NX objects can be categorized as follows:
UF objects (i.e. those documented in uf_object_types.h)
For the most part, there are distinct functions that may be applied to objects of a given class.
There is an additional class of objects that can be accessed via Open C and C++: Parasolid objects. (Parasolid is the geometric modeler that NX uses internally.) Parasolid objects are also identified with a tag but Parasolid tags and NX tags are incompatible. Parasolid tags are only used in the routines that can be found in the header file uf_ps.h. Although we generally discourage writing applications that mix Open C and C++ API and Parasolid routines, the routines in uf_ps.h allow you to directly access the underlying Parasolid objects that are embedded in the NX model or embed new Parasolid objects into the NX model.
还有另外一种对象类可以被Open C和C++所访问：Parasolid对象（Parasolid是NX的几何建模内核）Parasolid对象也可以用标签所标识，但是Parasolid标签和NX标签是不兼容的。Parasolid标签只用于能在头文件uf_ps.h下找到的例程所使用。虽然我们一般不建议混合Open C和C++以及Parasolid例程来编写应用程序，但是uf_ps.h头文件下的例程能使你直接访问嵌入NX模型下的Parasolid对象，或者嵌入新的Parasolid对象到NX模型中。