Select the listing device. The listing device can be set to a file,
the listing window, or both file and listing window. The listing
device can also be set to no output.

0 = Success
2 = Listing device is unavailable
otherwise an error code

Internal and External

UF_UI_open_listing_window
UF_UI_close_listing_window
UF_UI_write_listing_window
 

gateway

uc4403 write character string to listing device set by call to uc4400
if you only need to write to the listing window
(as opposed to a listing device set by uc4400)
this function may be replaced with UF_UI_write_listing_window
 

gateway

uc4404 write character string and integer to listing device set by uc4400
if you only need to write the data to the listing window
(and not a particular device set by uc4400)
this function may be replaced by UF_UI_write_listing_window
 

gateway

uc4406 write character string and real to listing device set by uc4400
if you only need to write the data to the listing window
(and not a particular listing device set by uc4400)
this function may be replaced by UF_UI_write_listing_window
 

gateway

Query the current disposition of the listing device.

Internal and External

0 = Listing device is set to the listing window
4 = Listing device is set to a file
8 = Listing device is set to both file and the listing window
9 = Listing device is set to NULL
otherwise the return is an error code.

UF_UI_open_listing_window
UF_UI_close_listing_window
UF_UI_write_listing_window
uc4400
 

gateway

Query the current NX Open program environment for the current image.

Note: This value is updated during initialization so it is set for
each image and won't remember the information from previous images.

Internal and External

Void
 

gateway

uf4401 opens the listing device set by uc4400 for output
if you only need to open the listing window for output
(and not a particular listing device set by uc4400)
this function may be replaced with UF_UI_open_listing_window
 

gateway

uf4402 closes listing device set by uc4400
if you only need to close the listing window
(and not a particular device set by uc4400)
this function may be replaced by UF_UI_close_listing_window
 

gateway

Registers the callback to be called whenever the reason specified
occurs within NX.

Please note the following:

Once a routine is registered as a callback, the shared library it
resides in should not be unloaded until it is deregistered.

The callback function must call UF_initialize and UF_terminate, if
it makes any Open C function calls

The callback function receives three arguments:
argument 1 - The reason the callback has been called
argument 2 - A pointer to the part tag that caused the callback.
argument 3 - A user supplied pointer. Typically this will be a
structure pointer of data that the callback function
will need.

The callback will be called towards the end of the processing for that
particular reason. For example, the callback registered against
UF_create_part_reason will be called when a new part is created, after
almost all the process of creating this new part is completed.

The only exception to the above is UF_close_part_reason, for which
the callback will be called at the beginning of closing the part.

NOTE: For the new and open part reasons the callback is run at a time
when the newly created or opened part has not been set as the work part.
Also operations such as create part, open part, save part or change display part
should not be called from callbacks fired by any of these same operations.

Internal and External

UF_remove_callback_function
UF_callback_reason_e
Refer to the example of setting up a callback.

V16 was changed to require the callback to call UF_initialize
 

gateway

Allocates a block of storage and returns a pointer to it. Use UF_free
to free the allocated memory when no longer required.

void - a pointer to the block of storage, aligned so
that any data type can be stored in it.
when error occur or nbytes = 0, a NULL pointer
is returned

Internal and External

This function was originally released in V15.0
 

gateway

Returns the current application module. The value that is returned
maps to a string defined constant. You can find the string in the
header file uf.h. The strings are of the form UF_APP_<module>.
For example, UF_APP_DRAFTING represents the drafting module.

Note - if this function is called from an external program it will
always return a FALSE and an app id of APP_NONE.

Internal and External
 

gateway

Returns the code set identifier supported by a machine. The code set
identifier can be any one of the enumerated constants in UF_codeset_e.

Internal and External

UF_codeset_t
 

gateway

This routine is used to receive arguments from a grip program. The
grip program sets up these arguments with the GRIP command, GRARGS.
The GRIP program then invokes execution of the internal Open API program
with the GRIP XSPAWN command. The Open API program, during execution,
maintains complete control of the system including any interactive
statements or error messages.

To receive the arguments from GRIP, define the structure, UF_args_s, that
describes the arguments to share with the GRIP program. This definition
must match the definition supplied to the GRIP GRARGS command so that the
contents of the GRIP variables can be copied to the contents of the Open
API variables.

Please note the following limitations:
. The GRARGS command is limited to 103 arguments.
. The size of character strings input to UF_ask_grip_args should be
declared to the largest GRIP string (132 characters) plus a null
character or 133 characters.
. Calls cannot be nested. For example, a sequence where GRIP XPAWNs an
internal Open API program which uses UF_call_grip to execute GRIP,
and anything similar, is not allowed.

Internal

See the example
which is called by this grip program.
 

gateway

Get name of the current syslog

Internal and External

Released in NX2.0.5
 

gateway

Get the information about an Open C Program

This routine can be used to gather the system information of an Open C
program, like the machine name, Operating System information etc., and is
useful in benchmarking, where you want to record the information about
the machine the benchmark was run on.

This routine outputs the data through the structure UF_system_info_t.

Once the data is no longer needed, the memory allocated to the fields
of this structure should be freed by a corresponding call to the routine
UF_free_system_info.

Internal and External

UF_free_system_info
UF_system_info_t

Released in V18.0, modified in NX 6.0 to return used bundles
 

gateway

Start a timer.

This routine can be used to gather timing information about an Open C
program, and is useful in benchmarking. This routine will start a timer.
The timer will be stopped with a corresponding call to UF_end_timer.

More than one timer can be active at any time, this is useful when you
have one overall timer, and then several sub-timers timing individual
sub-operations.

Internal and External

UF_end_timer
UF_timer_values_t

Released in V18.0
 

gateway

Calls and executes a GRIP program. Your GRIP program must be written,
compiled, linked, and ready to run.

While a GRIP program executes, it can have access to an Open C API function
arguments and their contents. Argument passing to the GRIP program occurs
through UFARGS. After GRIP program termination, the Open C API program has
access to any assignments made by the GRIP program. The GRIP program
completes its execution and then UF_call_grip outputs a return value.

Note: If the path is omitted in the grip_executable string passed to
UF_call_grip, NX will look in the current directory for the grip program.
It will not look in the directory of the ufunc program or use any
environment variables, including UGII_INITIAL_GRIP_DIR, to search for the
GRIP program.

UF_translate_variable can be used to extract an environment variable and
concatenate it with the program name.

The following GRIP commands are not
supported in External mode when calling GRIP:
ALL OF GRIP NC
PLNOTE EDTXHT CHAIN
BLANK UNBLNK RVBLNK
If any of these commands are encountered, an error is written to the
batch log file.

Internal and External

See the example
which calls the grip program.
 

gateway

Decodes an input authorization file using an integer key value that
matches the original key for perturbation.

NOTE: See %UGII_BASE_DIR%\UGALLIANCE\alliance_readme.txt for more information

Internal
 

gateway

Encodes an input authorization file using an integer value for
perturbation.

Internal
 

gateway

Stop the timer and get the timer values

This routine is used to gather timing information about an Open C program,
and is useful in benchmarking. This routine will stop the timer created by
a corresponding UF_begin_timer call, and output the timing information in
the structure UF_timer_values_t.

Internal and External

UF_begin_timer
UF_timer_values_t

Released in V18.0
 

gateway

Find all subdirectories of a given name in the directories specified in
the file custom_dirs.dat and ug_custom_dirs.dat. Since the same
subdirectory may be in multiple directories, an array of path names
will be returned. As an example searching for the subdirectory "startup"
will return almost all of the directories, since this is a standard
subdirectory.

Internal and External

UF_find_file

Released in NX 1.0
 

gateway

Find a given subdirectory and file. This routine will traverse all the
directories specified in the file custom_dirs.dat and ug_custom_dirs.dat
looking for the file specified by the given subdirectory and filename.
This routine will return the first file found.

Internal and External

UF_find_all_subdirectories

Released in NX 1.0
 

gateway

Frees the memory allocated and returned by an Open C API routine.

void

Internal and External
 

gateway

Frees the memory allocated for an array of pointers and frees the
strings within the array. You must pass in the number of pointer in
the array. Various Open C API routines malloc space for an array
of pointers, and then allocate space for each of the pointers.

void

Internal and External
 

gateway

Free the fields of the structure UF_system_info_t, containing the process
information

This structure is filled earlier by a call to the routine UF_ask_system_info

Internal and External

UF_ask_system_info
UF_system_info_t

Released in V18.0
 

gateway

This routine retrieves a customer default value from the database.
There are several different conditions that can arise from querying
the database:
1) The record was found and its units match. The function
returns SUCCESS(0)
2) The record was not found. If units given was ENGLISH or METRIC
nothing is returned and the function returns a FAILED(1). If
the units given was NONE a second and/or third attempt is made
with units ENGLISH THEN METRIC used instead. The results of
these attempts can be any of the conditions outlined above.

If you specify either METRIC or ENGLISH for units, this function
automatically appends _MU or _EU to the input name. For example, if you
specify METRIC and input the name "UG_gridSpacingY", the function searches
for "UG_gridSpacingY_MU".

If you specify NONE for units, the function searches for the name
as specified. If the name is not found it searches again with _EU
appended to the name. If the name is still not found, then it
appends _MU to the name for its final search.

return code:
0 = Success
1 = Record not found
<0 or >1 = Use UF_get_fail_message to get error.

Internal and External

See the example
 

gateway

Returns the message string associated with an error code.

Internal and External
 

gateway

Returns the current major release version number. For example, if
you call this function from V10.4.1, it returns V10.4. You must use
UF_free to deallocate space used by release.

Internal and External
 

gateway

Returns the licenses that are currently reserved against a context.
This method will also output the licenses reserved against the default context in the syslog.

Internal and External
 

gateway

Returns the message string associated with an error code in current user interface language.

Internal and External

Originally released in NX 10.0
 

gateway

Initializes the Open C API environment and allocates an Open C
API execute license. If you do not call UF_initialize, then subsequent
calls to Open C API fail with an error code of
UF_err_program_not_initialized. This function must be the first
function you call after you have declared your variables.

In external mode, you may only call UF_initialize once. Once
UF_terminate is called, there is no way to reconnect to the Open C environment.

Programs need to call UF_terminate before exiting to ensure licenses are
released and avoid errors in downstream NXOpen programs.

Internal and External

Refer to the UGII_UGOPEN_SESSION variable
 

gateway

Same as UF_initialize with the addition that Direct Model is also initialized.

Internal and External
 

gateway

Checks if the Open C API environment has been successfully
initialized.

return code:
0 = Open C API is not initialized.
1 = Open C API has been properly
initialized.

Internal and External
 

gateway

Checks to see if an NX Manager process is
active. It returns true if NX Manager is active.

Internal and External
 

gateway

Loads the shared library specified by library_name and finds the entry
point specified by symbol_name in that library. The reference to the
specified entry point is output as a function pointer declared to accept
and return void (i.e. type UF_load_f_p_t).

For the entry point to be found on Windows NT, you must declare it with
the DllExport macro, e.g.

extern DllExport int my_function(...

without the DllExport, the name will not be exported. Since the DllExport
also works on Unix systems, the best practice is just to always use the
DllExport macro for routines you want exported.

If library_name is found but symbol_name is not, an appropriate error
code returns, but the loaded library may not be unloaded. The user
should call UF_unload_library to explicitly unload library_name on
failure, if appropriate.

To load a shared library into an external application - the library must
not be linked against any interactive libraries. This can be accomplished
by using the "-noui" option on Unix.

NOTE: UF_load_library is intended for function (i.e. "text" entry
point) lookup only. It should NOT be used for data symbol lookup.

Internal and External

UF_unload_library
The UF_load_library example is split into an, internal program
which is loaded by the external program.
 

gateway

Each part file has an internal history storage area where the program
name can be stored when the system saves the part file. This function
enables you to specify either the entire program name (External
mode) or append a name to the program name (Internal mode). You
should call this routine before you call UF_PART_open since it does
not set the program name on parts that are already opened. A utility
called ug_inspect enables you to read the program name stored in the
history area.

Interactively (Internal mode), when you are in NX, the program
name will take the version of NX currently being run (e.g. NX9.0.0.19)
and append the string being passed into UF_MISC_set_program_name. For
example, if you specify "XYZ version 9.0" as the name string to this
routine, then the program name in the history would look like:
NX 9.0.0.19XYZ version 9.0
To separate the version and string, put a leading space in the name being
passed into this routine. " XYZ version 9.0" passed in will create:
NX 9.0.0.19 XYZ version 9.0

Once UF_terminate is called, the appended string is removed and it will
default back to the NX version number the next time the part is saved.

In External mode, the program name is what you specify in the name
string. From our previous example this would be XYZ version 9.0.
The limitation for the length of the name string depends on which
mode you are in, Internal or External. The maximum length of the
entire program name is 128 characters. In Internal mode, because the
name string is concatenated to the program name you are limited to
64 characters. In External mode, since the name string you specify
becomes the program name you are limited to 128 characters. In
either mode, if you specify a name that is to long, the name is
truncated to either 64 or 128 characters (Internal and External mode
respectively).

The internal history area is like a log file. If you resave the part file
with a different program a new history entry is added to the part file.
That is, the history grows larger. Thus you are likely to see two lines of
history if you have saved the part file twice and specified a name with
each save.

void

Internal and External
 

gateway

Output a message to the syslog.

This message can be used to print run time information about the NX Open
program to the syslog and is useful for state checking, validation and
debugging.

Printing the trace is especially useful while debugging and reporting a
problem.

Internal and External

Released in V18.0
 

gateway

Reallocates a block of storage and returns a pointer to it. Use UF_free
to free the allocated memory when no longer required.

void - a pointer to the block of storage, aligned so
that any data type can be stored in it.
when error occur or nbytes = 0, a NULL pointer
is returned

Internal and External

This function was originally released in V16.0
 

gateway

Release a license against the specified license context.

Internal and External
 

gateway

Release all licenses against the specified license context. If
the context specified is a user-defined context it will be deleted.

Internal and External
 

gateway

Deregisters the callback specified by the identifier.

Internal and External

UF_add_callback_function
 

gateway

Reserve a license against the specified license context.
If the specified user-defined context does not already exist it will be created.

Internal and External
 

gateway

Updates the contents of the matching GRIP argument list with the
contents of the Open API addresses. This is used to return data
to the GRIP program.

Internal
 

gateway

Set a flag that determines if an Open C executable will issue
warnings when a function that is scheduled to be retired is called.
This can be used to alert the NX Open programmer that modification to
their program is required.

When routines are planned to be removed from the NX Open interface, the
prototype will be moved to uf_retiring.h, along with a description of
what the NX Open programmer should do. A warning can be issued when
any of these routines are called by an NX Open application. This routine
allows the NX Open programmer to set the value of this flag.

This routine overrides the environment variable
UGII_USING_RETIRING_FUNCTIONS which can be set by the user to get
the same warnings. This routine is meant to be used when the programmer
wants to force a particular value for a program.

Internal and External

Released in V16.0
 

gateway

Sets an environment variable to the string specified in value. You must
supply the complete name of variable.

Internal and External

See the example
 

gateway

Force NX to shut down immediately. This is a substitute for the standard
c function: exit(0)

Warning: depending on the current state of NX, forcing a shutdown
may produce warnings/errors as NX attempts to close itself.

Internal and External

NX 6.0.1
 

gateway

This function replaces UF_TAG_ask_handle_of_tag.

Return the persistent HANDLE for an object tag.

Multiple parts can be loaded into NX during a single session, and
the Tag (i.e. Object Identifier) cannot be guaranteed between sessions.
Consequently, "handles" were created to identify objects between sessions.
This handle is persistent between sessions once the object is saved to a part file.
A handle of a new object in this session which is never saved is not guaranteed
to stay the same until the object is saved. Recreating the same object in a new
session may not be the same even if seemingly identical steps were taken to create
the object. This is particularly true across versions of software.

Handles should not be compared directly for checking identity as they contain
version information. Handles should be broken apart using UF_TAG_decompose_handle
and the file_data strings compared and the sub_file_id integers compared but the
version should be ignored.

Operations which change the name of the part will change the handle as well - so
"Save As" will cause handles to change.

This function will return an error when the part data of the handle
contains a character that cannot be represented. For this reason
it is suggested that UF_TEXT_set_text_mode(UF_TEXT_ALL_UTF8) be
set when you are working with handles that may come from parts that have
characters that are outside of your locale (e.g. parts with Japanese
characters on an english system).

Output:
The name of handle for object tag. This string must be freed by calling UF_free.

Internal and External

UF_TAG_ask_tag_of_handle

Originally released in NX 10.0
 

gateway

Returns the new tag of the object corresponding to the known object
ID in the V9 part. This only works for the Object IDs of the last V9
part loaded into this session.
NOTE: This was renamed from UF_ask_new_tag_of_entity()

New tag

Internal and External

UF_TAG_ask_handle_from_tag
 

gateway

Return the object tag of a persistent HANDLE.

Returns object tag of object handle

Internal and External

UF_TAG_ask_handle_from_tag
 

gateway

Given the constituent parts of data manager, filename, subfile id and
version, this function returns the resulting handle.

Internal and External
 

gateway

Given the handle, the constituent parts of data manager, filename, subfile
id and version are returned.

Note this function will return an error if you have UF_TEXT_set_text_mode()
set to locale and the file that the data is coming from has characters
outside of your locale. It is suggested that you set your text mode to
UF_TEXT_ALL_UTF8 when you are working with handles.

Internal and External

UF_TAG_ask_new_tag_of_entity
UF_TAG_ask_handle_from_tag
 

gateway

Register a new tag event callback. All callbacks are called on all tags
for all events. This returns an identifier for the callback which is
used to allow it removal.

Please note the following items:
. The routines registered can not call any other Open C routines
In particular, the tag cannot be queried or edited in any way.
. The implementation of any routine so registered must be very
efficient as it is called many times.
. Recall that tags get reused. This means that the order of events is
important so the event is interpreted with respect to the right
"incarnation" of the tag.

Internal and External

UF_TAG_unregister_event_cb

This function was originally released in V15.0.
 

gateway

Unregister a previously registered callback.

Internal and External

UF_TAG_register_event_cb

This function was originally released in V15.0.
 

gateway

Terminates the Open C API environment and deallocates a
Open C API execute license. If UF_terminate is not called, the
Open C API execute license may not be freed. Once UF_terminate
is called in an external Open C API program, the program will
exit. You will not be able to call UF_initialize again and continue
operation.

Calling this method will release all licenses in the default context.

Once UF_terminate has completed in an external program, you can no
longer write to the console window. It must be reinitialized with system
calls.

Internal and External

Refer to the UGII_UGOPEN_SESSION variable
 

gateway

Translates environment variables to their equivalence strings. You
must supply the complete name of the variable argument. The pointer passed
back points to an operating system string. This string must not be changed.

Internal and External

See the example
 

gateway

Unloads the shared library specified by library_name. UF_unload_library
unloads the library unconditionally, effectively invalidating all function
pointers previously set by calls to UF_load_library for the specified
library.

Internal and External

UF_load_library
The two UF_load_library example one and
example two use UF_unload_library.
 

gateway

Internal Open API Entry Point.

You use ufusr as a main function entry point for all Internal Open API
programs. The ufusr function may also be used for user exits.

For internal programs written in C, a third argument needs to be
passed into the "ufusr" function. This third variable is the length of the
character array param.

void

Internal

ufusr_ask_unload
See the discussion on user exits in uf_exit.h
Refer to the example of an internal program.

User supplied routine to specify how an Internal Open API shared image
is handled upon exit. This function gives you the capability to unload an
internal Open API or user exit from NX. You can
specify any one of the three constants as a return value to
determine the type of unload to perform: immediately after Open
API execution, via an unload selection dialog, or when NX
terminates.

If you choose UF_UNLOAD_SEL_DIALOG, then you have the option to unload
your image by selecting File--Utilities--Unload Shared Image.

Please note the following restrictions:
A program which uses UF_UI_append_menubar_menu should not
use the option to unload an Open API image. Additionally, if
your code which defines UF_UI_append_menubar_menu itself
loads a shared library, this code should not attempt to unload the
library. NX always makes a strong attempt to prevent
unloading a library which was coded by using UF_UI_append_menubar_menu.

A shared library that contains registered functions, such as any of
the User Defined Object registration methods, should not be
unloaded. NX must keep the library loaded to access the
address of the registered function.

Unload immediately and Unload via dialog should not be used if the
program has registered any sort of callbacks.

Additionally, you have the option of coding the cleanup routine
ufusr_cleanup to perform any house keeping chores that may need
to be performed. If you code the cleanup routine it is automatically
called by NX.

UF_UNLOAD_IMMEDIATELY - unload immediately after Open API executes
UF_UNLOAD_SEL_DIALOG - via an unload selection dialog
UF_UNLOAD_UG_TERMINATE - when NX terminates

Internal

ufusr
See the example

User supplied routine to clean up before the user function program is
unloaded.

NX calls this entry point if it is defined in your source code.
The entry point is called immediately before a shared library is
unloaded and allows you to perform any cleanup tasks that must be
performed within NX. For example, if your internal program
opened up a database program you could use the call to
ufusr_cleanup as an opportunity to close any open database files
before the image is unloaded.

NOTE: You use ufusr_cleanup in conjunction with ufusr_ask_unload.
If you code ufusr_cleanup without defining ufusr_ask_unload, then
the ufusr_cleanup entry point is ignored.

void

Internal

See the example