Functions | |
void | Show_Selection_Pathname (char *segment) |
void Show_Selection_Pathname | ( | char * | segment | ) |
Returns the fully-qualified name of the segment that was selected by the user.
segment | - The full name of the segment that includes the window or piece of geometry that was selected in the current event. Passed by reference always. Returned to user. |
The thought behind returning the simple name is that a single (hopefully meaningful) word---such as "orbit" or "exit"---is easy for your program to parse, recognize, and do something about. However, the simple name might be ambiguous, if two or more segments that you want to treat differently have the same name but different owners. It might also be hard to get the system to accept the simple name back again as a valid segment specification, unless the owning segment also happens to be the currently open segment.
If the path involves one segment including another, the pathname returned will be the name of the lowest level segment, a < sign, the name of the segment that did the including, and another < sign, etc. The < means "as included by". All HOOPS routines will accept segment names with <'s: unfortunately, they discard the information after the < rather than checking it or parsing wildcards there. So the usual use of these compound-pathnames is to have Parse_String() take them apart, then you can make use of the pieces by hand.
Suppose there is an include segment with a pathname such as
/include/a/bwherein "a" contains a matrix, and "b" contains geometry. This segment is used in a scene as follows:
Open_Segment ("?picture") Include_Segment ("/include/a") Include_Segment ("/include/a/b") Close_Segment()The HOOPS picture in this case would show two versions of the geometry, as one would expect. However, the include pathname construct described above would have returned the same path for selections of different instances of "b":
/include/a/b < /driver/msw/window0Therefore, HOOPS adds additional arrows to indicate that the selected instance belongs to a containing segment. Thus, a selection of the direct instance of "b" will be
/include/a/b < /driver/msw/window0but a selection of the geometry instanced by an include of the "a" segment will return:
/include/a/b << /driver/msw/window0Note that the offset of the containing segment in the absolute path is equal to the number of arrows. For instance:
/include/one/two/three <<< /driver/msw/window0indicates that segment /include/one was originally instanced, while
/include/one/two/three << /driver/msw/window0
indicates that segment /include/one/two was the original.
If the path involves a geometry reference, the function will return a path that is fully rooted, starting with a "/" with any geometry reference denoted with the "@hexkey" format (as for unnamed segments). If any references are in the path, they necessarily appear directly following the selected segment, with a single < per reference. The last reference in a chain (or the only reference) will have a ":" and the full path of its owning segment appended. Here's how to parse the following returned pathname:
/include library/block/btable_101a/btable_model_space/entity_7ee7a360 < @810A95E8:/include library/model_0/i0/btable_model_space/entity_7ef7bca0 <<<< /driver/opengl/window0+0/scene/overwrite/selectionconditionincluder.