注册 登录  
 加关注
   显示下一条  |  关闭
温馨提示!由于新浪微博认证机制调整,您的新浪微博帐号绑定已过期,请重新绑定!立即重新绑定新浪微博》  |  关闭

信息 灵感 创新

I? =Information,Inspiration,Innovation

 
 
 

日志

 
 
关于我

we are 5. Mathematics, Computation, Programming, Engineering, and Making fun of life.

网易考拉推荐

Open C Programmer's Guide  

2014-06-11 14:59:39|  分类: UG NX |  标签: |举报 |字号 订阅

  下载LOFTER 我的照片书  |

注:本文摘自NX的帮助文档。

Open C Programmer's Guide

Introduction

Open API (User Function) is a collection of routines that allows programs to access and affect the NX Object Model. In addition to the routines, there are tools provided to compile and link programs in a manner consistent with what NX expects.

Open API programs can run in two different environments, depending on how the program was linked. The two environments are:

External: These programs are standalone programs that can run from the operating system, outside of NX, or as a child process spawned from NX. Although external programs do not have a graphics display, the API provides functions that allow plotting and the creation of CGM files.

Internal: These programs can only be run from inside of an NX session. These programs are loaded into the NX process space. One advantage to this is that the executables are much smaller and link much faster. Once an Internal program is loaded into memory, it stays resident for the remainder of the NX session unless you utilize the facilities within the API to unload it. The results of internal API programs are visible in the graphics window of an NX session.

What Is the Open API?

Open API is a product name that encompasses the flexible integration of many different software applications with NX through an open architecture. The intent is for the integrated applications, along with third party and NX applications, to share data on different computer platforms, from different locations (heterogeneous network), and even access its content over the Internet. Open API, by design, focuses on enabling open architectures to be utilized by third parties, customers, and in-house users when integrating or customizing software applications.

The Open API provides the applications and tools that enable customers to:

?Interface with the NX Object Model through Open C and C++ API or GRIP.

?Create and manipulate User Defined Objects (also referred to as Custom Objects) including managing their associativity with other NX objects and providing methods for updating and displaying the User Defined Objects.

?Customize the NX graphics interface to reflect third party applications.

?Take advantage of related products such as, Teamcenter engineering process management ITK, and Parasolid.

?Utilize and integrate new Open API technologies as they become available.

The key idea is to provide many applications (applications can consist of third party, integrated, and NX applications) that enable customers in geographically diverse locations to work simultaneously on information which they can share throughout their enterprise. The reason for providing such applications is that in order to support global manufacturers' Fast-to-Market and/or Global Integration strategies they need solutions that allow geographically diverse locations and multi-disciplinary teams to collaborate more effectively on designing, developing, and manufacturing mechanical products. For example: collaboration between geographically different product development sites, between different companies allied to jointly develop products, between designers and engineers/analysts, between designers and machinists, between product development and manufacturing sites, between manufacturers and their suppliers, etc.

Relationship to User Function

User Function is the legacy name for the programmatic interface to NX. We refer to User Function as the Open C and C++ API. Note that Open C and C++ cooperate with the GRIP product and data can be shared between the two.

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.

Tags

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)

?expressions

?parts

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.

Basic Part File Query

This section provides a description of how to perform a basic part file query and answers the question "How Do I Cycle the Data Model?" by examining presupplied example code. We supply both an internal and external version of the cycle program. These versions illustrate that although the internal and external environments are different, with some thought, much of the code necessary for either version can be developed once and shared. Thus, there are not two completely different versions, but one program with two unique interfaces. The following files provide the code for these two versions. All of the files are available on the CD in the Open API kit.

ufx_cycle.h

Contains prototypes of functions that are common to both internal and external Open C and C++ API programs.

ufx_cycle_common.c

Includes the code that is used by both the internal and external versions of the "Cycle the Data Model" program. It does all the work of getting the part file history, cycling the model, and printing a report on its results.

ufx_cycle_external.c

This is the external Open C and C++ API source code for cycling the data model of a part. This version acquires its part file name from the command line.

ufx_cycle_internal.c

This is the internal Open C and C++ API version of cycling the data model. This version acquires its part from a multiple menu which allows you to either cycle the current work part or specify another part to cycle.

The example code demonstrates how to build both internal and external programs from the ground up.

What Do the Programs Do?

Both internal and external versions use the same code to:

?open a part.

?get and print a report on the part file's history, attributes, status, customer area, and description area.

?cycle the objects in the part.

?print a count of objects for each object type.

?print a count of: the total number of objects, displayable objects, and condemned objects.

?print the count of objects on customer accessible layers.

The difference between the internal and external versions is in the method used to acquire the part to operate on. A detailed discussion of both programs occurs in later sections of this section.

MenuScript 

The functions prototyped in uf_mb.h provide the programmatic interface to MenuScript. The MenuScript product:

?lets NX customers and third-party developers use ASCII files to edit NX menus and create custom menus for their own applications in an integrated, seamless manner. Menu files support custom tailoring of the main menu bar and the Quick View Pop-up menu.

?supports pre and post actions for menu items, providing a capability similar to that of User Exits, for both standard NX menu items and those provided by third-party applications developed with Open C and C++.

?provides a Menubar Report Tool to help review menu customization, diagnose problems, and assist in upgrading to future NX releases.

?provides for extensive customization of NX menus including adding, removing, and rearranging menu items, and duplicating or moving menu items from the main menu bar to the Quick View Pop-up menu. Added menu items can execute existing GRIP or Open C and C++ API programs, perform system commands (including running a program or script), open a User Interface Styler dialog, or open a User Tool palette.

Note

You cannot use Menuscript to rearrange NX buttons or clone existing buttons on the menu. To do this, use Tools→Customize.

All of these customization techniques can be accomplished without requiring any C programming. These capabilities, along with complete information on the format and usage of MenuScript menu files, MenuScript environment variables and command line arguments, and the Menubar Report Tool are included in the MenuScript Help.

Note

The following notes apply to this chapter:

?You must be thoroughly familiar with the information in the Open MenuScript Help to use the functions documented in this chapter. Please review the information in the Help prior to using the MenuScript API.

?In the examples and illustrations, the directory /custom/menu is used. It is assumed that this directory has been placed in the file pointed to by UGII_CUSTOM_DIRECTORY_FILE on the users system. This file contains a list of directories which NX still search for customizations like the ones described here.

?In the illustrations, the shared libraries that are shown use extensions. Please use the correct extension required for your platform, such as .so for Linux systems, .dll for Windows systems, and so on.

Open C and C++ API - MenuScript Functions

This section provides an overview of the MenuScript functions of the Open C and C++ API along with several abbreviated examples. Because detailed examples of locating and modifying menu buttons are provided in the MenuScript Help, the same level of detail is not repeated here. The only difference in using the MenuScript API is that actions specified via the ACTIONS menu file statement represent C callbacks registered via UF_MB_add_actions, rather than the names of existing GRIP or Open C and C++ API programs, or User Tool Definition (utd) files.

The primary capabilities of the MenuScript functions are the ability to register callbacks, written in C, that open dialogs or perform functions that you have developed using Open C and C++ and the ability to register a complete application to add to the NX menu bar. UF_MB_add_actions allows you to bind each callback and an associated callback data pointer to an action name defined as a character string. You can then specify an action name on the ACTIONS menu file statement. When a menu file is being read, each time an action is encountered, the action name is located in the action registration table, and the corresponding callback is attached to the menu item.

Creating and Adding Actions

You can use MenuScript to add your own functions to extend the capabilities of the Gateway application (i.e. your menu items are present throughout the entire NX session), or to extend the capabilities of a specific application such as Modeling, Drafting, or Manufacturing. In the latter case, your menus items are present only while you are in that application, and are automatically added and removed for you each time you enter and exit the application in the same manner as is done for application-specific standard NX menu items.

The registration of your callbacks via UF_MB_add_actions must take place prior to reading the menu file that references these actions. If the functions you are providing extend the capabilities of Gateway and are present on the menu bar throughout the NX session, then this registration should be done in a shared library placed in a directory named startup. This directory should be a subdirectory of one of the entries in the file pointed to by the environment variable UGII_CUSTOM_DIRECTORY_FILE. Shared libraries and menu files placed in these startup directories are automatically loaded during NX startup. For each shared library loaded, the ufsta entry point is executed immediately after loading the shared library. The call to UF_MB_add_actions should be placed in the ufsta routine. Please refer to the MenuScript Help for complete information on MenuScript environment variables, directories, and menu files.

If the functions you are providing extend the capabilities of a NX application such as Modeling or Drafting, and you want these functions to be available only while you are in a specific application, the shared library should be placed in the subdirectory called application. Your application-specific shared library and application-specific menu file can then be referenced on the application button's LIBRARIES and MENU_FILES statements, respectively, as shown later in a more detailed example. In this case, loading of your shared library and menu file are deferred until you enter the application, and any menu items you add are automatically added and removed from the menu bar or Quick View Pop-up each time you enter and exit the application.

For example, assume you have used Motif and Open C and C++ to provide a function that creates a housing from a parametric definition. Your dialog first allows the user to select settings for various parameters and then creates the housing using a number of functions provided by the modeling functions of Open C and C++. The code for registering your callback might look like:

static UF_MB_cb_status_t create_housing_callback(

      UF_MB_widget_t             widget,

      UF_MB_data_t         client_data,

      UF_MB_activated_button_p_t call_button );

static UF_MB_action_t actionTable[] =

{

      {"create_housing",create_housing_callback,NULL},

      {NULL, NULL, NULL}

};

extern void ufsta( char *param, int *retcod, int param_len )

{

         int status;

      UF_initialize(); /* Initialize Open C and C++ API */

      status = UF_MB_add_actions( actionTable );

}The menu file to add this button to the end of the Toolbox menu when you enter modeling would contain:

VERSION

EDIT UG_GATEWAY_MAIN_MENUBAR

MENU UG_MODELING

BUTTON CREATE_HOUSING

LABEL Create Housing...

 

ACTIONS create_housing

END_OF_MENU

Use of the menu file commands, BEFORE or AFTER, described in the MenuScript Help, provide additional alternatives for more precisely controlling the placement of this menu item. Note that for this example a second menu file is required to add your shared library and menu file to the Modeling application button.

Help (uf_help.h)

Open C and C++ routines in this section are for users and third party vendors who want to implement context sensitive help for Dialog Area 1 (DA1) and Dialog Area 2 (DA2) dialogs.

The routines in this section allow you to:

?Manage translation map files for context sensitive help.

?Manage the application context stack.

?Display context sensitive help for the application context currently on the top of the stack.

?Display context sensitive help information.

Terminology

The following terms are used throughout this section.

Application Context

 A string, defined by the application programmer, that is used as a key to find a help topic.

Document Tag

A help file specific tag that points to a specific section in a help document. There is a one-to-one correspondence between an application context and a document tag.

NX Translation Table

Translation table used by NX to associate the Application Context to the Document Tag.

HTML file

Hyper Text Markup Language version of a help file that can be viewed using a standard browser. HTML is a non-proprietary format, based upon SGML, and is widely used for publishing hypertext on the World Wide Web (www). HTML uses tags to structure text into headings, paragraphs, lists, hypertext links and more.

The Context Sensitive Help Mechanism

The context sensitive help mechanism begins with calls made by the application developer to push application contexts onto a stack before entering a dialog. These application contexts are tracked by the help mechanism and capture the path the user has taken through the application. When the user requests context sensitive help, the help mechanism uses the application contexts to initiate the display of help.

The current application context from the stack is looked up in a translation table to find the display method and the actual document tag. The display method specifies a format type for the help, either HTML, plain text or .chm file (compiled help file). The document tag specifies the directory of the help files, and in the case of HTML and .chm file, a specific location within the document.

The following are the basic steps required for implementing context sensitive help.

1.Create help files. For HTML files you can include location anchors and hyperlinks that branch to other help files.

2.Create a translation table that establishes mappings between application contexts and the appropriate help files.

For help based on text or HTML files the mappings consist of individual document ids. For HTML mappings you can optionally include anchor locations.

3.Insert calls in the application code to push application contexts.

Context Sensitive Help Preparation

Which dialogs require specific help pages in a document must first be determined. The other items that require consideration are:

?Unique naming conventions.

?Creation of help files. These can be HTML help files, with optionally embedded positioning anchors, simple text help files, or an .chm file containing properly positioned alias tags.

?Creation of a translation table.

?Translation table syntax rules.

Naming Conventions

Application contexts should be unique across any translation tables that might be loaded at the same time so that name conflicts do not occur. We recommend that the application context and the alias tags be constructed with the vendor name along with the name of the function.

<Vendor_Name>_<Function_name>

For example, a vendor application with a parent dialog could use the following (assume the vendor name is "vnd"):

vnd_import

vnd_export

vnd_plot

vnd_fileUtilites

vnd_objectDisplay

User Defined Objects

A User Defined Object or UDO is an object that contains customer defined data and customer supplied associations. The UDO can be linked or associated with other NX objects including other UDOs. As the associated NX object changes, the UDO can be kept up to date. UDOs enable third party vendors and users to augment their part files with customer specific application data.

All UDOs contain:

UDO Name

This is a UDO class name specifier.

UDO Status

An integer value that specifies whether the UDO is up to date or out of date.

UDO can contain the following:

?Free form data that can consist of integers, doubles, and strings.

?Links to NX objects.

?Convertible data that can consist of lengths, areas, and volumes.

Additionally, all UDOs within a class may have their own methods to allow them to display, be selected, and to obtain real-time notification during update and delete events. The methods are registered as callback functions which occur at key events in a NX session.

Example Code

The files for an example program can be found in the ugopen directory. This program is an internal Open C and 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

The example is implemented using MenuScript and demonstrates the augmented associativity possible with UDOs by forcing notes to move with drafting views.

UDO Name

UDOs belong to a class and have a class name assigned to them at 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 generic 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.

Note

If user defined methods are used, then only status values 0 and 1 can occur.

Status Value

Description

1

UDO is out of date due to addition or deletion of links to the UDO.

2

UDO is out of date due to an update being performed on associated objects in the absence of a UDO method.

3

UDO is out of date due to an update being performed on associated objects in the absence of a UDO method and due to addition or deletion of links to the UDO.

4

UDO is out of date due to the deletion of associated objects in the absence of a UDO method.

5

UDO is out of date due to the deletion of associated objects in the absence of a UDO method and due to addition or deletion of links to the UDO.

6

UDO is out of date due to the deletion of associated objects in the absence of a UDO method and due to an update being performed on associated objects in the absence of a UDO method.

7

UDO is out of date due to the deletion of associated objects in the absence of a UDO method and due to an update being performed on associated objects in the absence of a UDO method and due to addition or deletion of links to the UDO.

 

  评论这张
 
阅读(1363)| 评论(0)
推荐 转载

历史上的今天

评论

<#--最新日志,群博日志--> <#--推荐日志--> <#--引用记录--> <#--博主推荐--> <#--随机阅读--> <#--首页推荐--> <#--历史上的今天--> <#--被推荐日志--> <#--上一篇,下一篇--> <#-- 热度 --> <#-- 网易新闻广告 --> <#--右边模块结构--> <#--评论模块结构--> <#--引用模块结构--> <#--博主发起的投票-->
 
 
 
 
 
 
 
 
 
 
 
 
 
 

页脚

网易公司版权所有 ©1997-2016