Functions | |
void | Show_Selection_Pathname (char *segment) |
Returns the fully-qualified name of the segment that was selected by the user. More... | |
Detailed Description
Function Documentation
◆ Show_Selection_Pathname()
void Show_Selection_Pathname | ( | char * | segment | ) |
Returns the fully-qualified name of the segment that was selected by the user.
- Parameters
-
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.
DETAILS
Show_Selection_Pathname returns information that is similar to the simple name returned by the Show_Selection() or Get_Selection() . The "path name" differs from the simple name in that it includes the segment's owner, the owner's owner, etc., separated by "/" marks in the usual way. It is long, but unambiguous and always legitimate.
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.
- The entity selected was a geometry reference as indicated by the '@' symbol
- The geometry reference has the HC_KEY (in hex) value 810A95E8
- The actual geometry (that is being referenced) lives in this segment: /include library/block/btable_101a/btable_model_space/entity_7ee7a360
- The segment that "owns" the geometry reference is:
/include library/model_0/i0/btable_model_space/entity_7ef7bca0
- ie, in this segment, there is a Reference_Geometry call
- this is indicated by the ':' symbol after the geometry reference key
- The grand-grand parent (ie, 3rd parent) of the segment in step 4 above is included by:
/driver/opengl/window0+0/scene/overwrite/selectionconditionincluder
- this is indicated by the 4 '<' symbols
- ie, in the segment /driver/opengl/window0+0/scene/overwrite/selectionconditionincluder, there was a HC_Include_Segment("/include library/model_0") call.
NOTES
Show_Selection_Keys returns the same information but in a different format.