NX 9 is not finding a table definition in a certain node in a RoutingPartLibrary, but NX 6 is.
However, I'm not sure whether the "table definition" type in NXOpen C++ is functionally equivalent to UF_EPLIB_part_table_t, so maybe I'm barking up the wrong tree.
The following logic works in NX 6:
1) get a UF_EPLIB_part_library_view_t* named "plv":
UF_ROUTE_application_view_t* apv = UF_ROUTE_ask_current_app_view();
2) recursively search the tree of plv->top for a UF_EPLIB_part_lib_view_node_t* "node" such that node->identifier matches a given string.
3) Do a bunch of stuff with the UF_EPLIB_part_table_t* at node->table (after verifying that node->table is not NULL).
I am now porting this to NX 9. I've been informed by a Siemens rep that UF_ROUTE_ask_app_view_plib_view is "obsolete" in NX 9, and indeed this method sets "plv" to NULL when I call it. So I am reimplementing my logic using the NX Open C++ API. My code does this:
auto plv = NXOpen::
auto tableDef = plv->GetTableDefinition(name);
(where "name" is the same string used in NX 6 to find the "node". As far as I know, all the data and inputs are the same, although perhaps someone can tell me whether the following behavior indicates this assumption is incorrect.)
This is failing (GetTableDefinition is throwing). I find that plv->GetNodeType(name) returns NXOpen:: Preferences::RoutingPartLibrary::NodeTypeNormal , but GetTableDefinition requires NodeTypeTable . So NX 6 is finding a table here, but NX 9 is not.
However, I'm not sure whether the "table definition" type in NXOpen C++ is functionally equivalent to UF_EPLIB_part_table_t, so maybe I'm barking up the wrong tree. What I need to do is the equivalent of iterating over the data array at UF_EPLIB_part_table_t::data , but I don't see anything that looks like "data" in the "table definition" structure returned by RoutingPartLibrary::GetTableDefinition.
Solved! Go to Solution.
Spoke with GTAC again, and found out the following:
1) There was a config error on my end -- my environment variables were still pointing to the NX 6 part table files, and the file names and formats are different in NX 9.
2) There is a bug in RoutingPartLibrary->GetChildren(NXString) wherein, if a client calls this method upon the name of a node that is not of type NodeTypeNormal, the internal state of NX gets corrupted. (The documentation on this method was missing a notice about this constraint.) Manifestations of this include access violations when calling GetPartDefinition, or subsequent calls to GetChildren throwing spurious exceptions with messages about the given node name not being found. (I'm not sure if this was also causing my failure in GetTableDefinition, because I fixed both this problem and problem 1 at the same time.)