• UDO Name – A UDO class name specifier.
• UDO Status – An integer value that specifies whether the UDO is up to date or out of date.
• Free Form Data – May consist of integers, doubles, and strings.
• Convertible Data – May consist of lengths, areas, and volumes.
• Links to NX Objects – There are five different types of links.

Additionally, all UDOs within a class may have their own methods to allow them to display, be selected, and obtain real-time notification during update and delete events.  The methods are registered as callback functions which occur at key events in an NX session. 
 
Warning:
It is important to ensure that the required libraries (containing the UDO’s classes and methods) are present in the environment before opening a part that contains a UDO.  NX will not issue any warning or notification about such missing libraries.  Classes and methods can be automatically loaded into NX during system initialization.

Due to an enhancement to User Defined Objects (UDOs) in NX 5, all part files that contain UDOs that were created before NX 5 need to be opened and saved in version NX 5, or later.

The refile_part utility can be used to upgrade parts in batch mode. This avoids errors that may occur when partial loading is used to open an assembly with components containing UDOs created in earlier versions of NX.
 
Sample Code
The files for two sample programs can be found in the ugopen directory. 
 
The first sample is an internal Open C API program that creates an Occurrenceable UDO.  The UDO is displayed as a circle centered on the face of a block.
See Occurrenceable UDO Sample for detailed instructions on how to compile, link and run this sample program.
 
 
The second sample is an internal Open C API program that associates notes with drawing views. 
The files for the example code are:
ufx_udo.h
ufx_udo_methods.c
ufx_udo_application.c
add_assoc_notes.men
assoc_notes.men
 
 
 
UDO Name
UDOs belong to a class and have a class name assigned to them during creation of the class.  There is also a “user friendly” name that can display which can be different from the actual class name.  The class name should not match the name of any NX object.  A class name should be specified as unique to a particular application so that there is no collision of class names from other applications.
 
The former Generic Entity (Object) is automatically upgraded to a UDO during part conversion.  Its UDO class name matches the sprintf string:
“Generic Entity – Subtype %d”
where the integer corresponds to the subtype for the existing geometric entity.  Therefore the class name for an existing generic entity with a subtype of 15 would be:
            “Generic Entity – Subtype 15”
You create the class and specify the name with UF_UDOBJ_create_class.  However, once a class is created, you can only access the class name through the query functions:
            UF_UDOBJ_ask_udo_data
and
            UF_UDOBJ_ask_class_data
 
 
 
UDO Status
An integer status value (1-7) is set for each UDO by NX in the absence of user defined methods.  You can obtain the status with the query function UF_UDOBJ_ask_udo_data and the value can be reset to zero with UF_UDOBJ_clear_udo_status.  The description for each status value is given in the following table.
 
 

• Lengths – an array that can contain any number of doubles where each double represents a unit of length (e.g. centimeters).
• Areas – an array that can contain any number of doubles where each double represents a unit of area (e.g. square meters).
• Volumes – an array that can contain any number of doubles where each double represents a unit of volume (e.g. cubic meters).

• If the UDO is deleted, then the link between the UDO and the associated object is removed and the associated object itself is deleted, if it is not a solid body.  If the owned object is a solid, then only the link is broken, and the solid body is left alone.
• The associated object cannot be deleted directly.  However if the owned object is a solid, then the solid may still be selected through modeling selection where the feature list is presented to the user.  For example, it may be deleted through EditàFeatureàDelete Feature.  This is because ultimately modeling is in control of all solid bodies.
• If the UDO is updated, then the associated object is unaffected.  However, you can cause the associated object to update by registering an update function to the UDO class.
• If an associated object is updated, the UDO is unaffected.

• Display – the three display events include: self display (including plotting and CGM file creation), attention point assignment, and fit to view.
• Selection – includes both single and class selection.
• Update – keeps all objects up to date as the model changes.
• Delete – realigns data in the free form and convertible data areas as associated objects are removed from the data model.
• Is Occurrenceable - determines if a particular UDO should display, select, update, or delete in an assembly.

• UDO arc
• UDO circle
• UDO polyline
• UDO points
• UDO polygon
• UDO text
• UDO facets

• UF_DISP_regenerate_display
• Any routine that Queries or Sets the Work or Displayed Part

• The display method is invoked by NX when the UDO needs to be displayed.  Display primitive routines should be called by this method to actually cause the UDO to display.  See UF_UDOBJ_register_display_cb.
• The attention point method is invoked by NX when the UDO’s attention point is determined.  See UF_UDOBJ_register_attn_pt_cb.
• The fit method is invoked by NX when an object is being fit into a view.  See UF_UDOBJ_register_fit_cb.

• ArrangeàAttributes
• EditàBlank
• EditàDelete
• EditàObject Display
• InfoàObject

• Never explicitly invoke the update process again.  This may occur by using UF_MODL_update, or by creating a new feature.
• Never change the work part.

• If the Owned object is allowed for selection, then picking the owned object will only select the owned object and the Up One Level button will be enabled.  Selecting the Up One Level button will result in the selection of both the owned object, and the UDO.  If the UDO is in turn an owned object, then the selection behavior will be dependent on whether or not the UDO (which is an owned object) is allowed for selection.
• If the owned object is not allowed for selection, then picking the owned object will result in the selection of both the owned object and the UDO.  If the UDO is an owned object, then the selection behavior will be dependent on whether or not the UDO (which is an owned object) is allowed for selection.

• UDO-1 owns Point-1 and UDO-2
• UDO-2 owns Point-2 and UDO-3
• UDO-3 owns Point-3

• Windows - .dll
• Linux - .so
• MacOS - .dylib

• Place code within the ufsta function that attempts to access a part or the user interface.
• Attempt to load or create a part within the call to ufsta.

• Use either UF_UDOBJ_create_udo_feature or UF_UDOBJ_create_udo_feature_from_udo to create the UDO feature.  The latter function is for legacy data and part conversion from previous releases.
• Use UF_UDOBJ_add_links to create the links required to update the UDO.
• Use UF_UDOBJ_add_owning_links to create the owned objects.

1. create feature BLOCK(0)
2. create feature TAPER(1)
3. create UDO

1. create feature BLOCK(0)
2. create feature UDO(1)
3. create feature TAPER(2)

1. create feature BLOCK(0)
2. create feature UDO(1)
3. create feature SWEEP(2)

• Info
• Edit Parameters
• Reorder
• Delete
• Suppress
• Unsuppress
• Suppress by Expression