Features, FeatureBuilder, and Custom Feature Classes

This page combines two levels of the "how features are created and edited" story in NX Open: the general Builder pattern described in the Common Object Model overview, and the more specialized Custom Feature classes used when defining entirely new feature types (User Defined Features via NXOpen, as opposed to the older UDF/UF mechanism).

The general Builder pattern (from the Common Object Model)

Part contains many TaggedObjectCollection members for obtaining/creating tagged objects — e.g. Part.Features is a collection of all features in the part, and can yield FeatureBuilder objects for creating or editing features.

Features (and many other entities) are created/edited through a Builder class:

• Builder classes expose methods (or .NET properties) to get/set the defining data for the entity, generally mirroring the corresponding UI command's input data.
• Builders can be queried for their current state.
• Call Commit to create the entity or apply edits.
• Call Destroy when finished with the builder, to release its resources.

This is the standard pattern you use for the vast majority of feature creation/editing in NX Open — e.g. obtaining an ExtrudeBuilder from the appropriate factory method, setting its section/direction/limits properties, then calling Commit().

Custom Feature Classes (defining new feature types)

When you need to define an entirely new kind of feature (rather than just create/edit instances of NX's built-in feature types), NX Open provides a dedicated Custom Feature framework under the NXOpen.Features namespace. You use five categories of classes:

1. Configuration classes

   • NXOpen.Features.CustomFeatureClass — responsible for storing the class name and callbacks for a given class. There is only one CustomFeatureClass instance for a given FeatureClass name in a session.
   • NXOpen.Features.CustomFeatureClassManager — a singleton obtainable from the session; manages the set of CustomFeatureClass objects.

2. Callback event classes — all derive from the base class NXOpen.Features.CustomFeatureEvent, which provides the basic operations required across all events:

   • CustomFeaturePreUpdateEvent — invoked before the update of the custom feature itself. You create construction features here and set them on the event.
   • CustomFeatureCreateFeatureGeometryEvent (referenced via its SetBodies method) — used to set the bodies produced by the custom feature. Caution: using Parasolid bodies from other feature bodies created by standard NX feature creation in methods like TrackingData or CustomFeatureCreateFeatureGeometryEvent.SetBodies could result in a corrupted model.
   • CustomFeatureModifyFeatureGeometryEvent — used to modify existing geometry; mostly for body-modifying features.
   • CustomFeaturePostUpdateEvent — invoked after the update of the custom feature itself. You can create output features here and set them on the event; the set feature becomes internal to the custom feature for which the event is invoked, enabling consecutive/chained calls.
   • CustomFeatureInformationEvent — lets you specify the information displayed when the user right-clicks the feature.
   • CustomFeatureHighlightEvent — lets you control highlighting of the custom feature.

3. Data structure / attribute classes (used to attach typed data to the custom feature):

   • CustomExpressionArrayAttribute — a collection of NXOpen.Expression.
   • CustomTagAttribute — wraps a single NXOpen.TaggedObject.
   • CustomTagArrayAttribute — a collection of NXOpen.TaggedObject.

4. Builder class

   • NXOpen.Features.CustomFeatureBuilder — the builder class specifically for the creation of custom features (parallels the general Builder/Commit/Destroy pattern above, but scoped to defining a new custom feature type).

5. Tracking data class

   • NXOpen.Features.TrackingData — tracks updates due to the custom feature. Providing consistent tracking data on every update is crucial for consistent update of downstream dependents. The custom feature is expected to produce some geometry (curves, bodies, etc.). Only entities created by the custom feature itself should be tracked — not entities created by its construction features or output features (which are tracked separately as their own features).

Related Topics

• Common Object Model (objectModel.md)
• Custom features overview
• Create custom features
• Attributes for custom features
• UDF hooks overview (the older, non-NXOpen User Defined Feature mechanism)

Note on scope

The full method/property signatures for CustomFeatureBuilder, each CustomFeature*Event class, and TrackingData (parameter lists, return types, exact overloads) live in the language-specific NX Open API references (nxopen-cpp-reference, nxopen-dotnet-reference, nxopen-java-reference, nxopen-python-reference), which are covered separately. This page preserves the conceptual architecture and every class name exactly as named in the source Programmer's Guide text.