Viewing Interface to Part Management


When PART is used in conjunction with GI viewing, the application can either provide its own interface or use the PART_CONTEXT.

The PART_CONTEXT class is an implementation of the RENDERING_MANAGER. PART_CONTEXT provides a means of connecting a part with GI. The interface to Scheme uses this.

A PART_CONTEXT is not required to connect PART with GI. The main advantage of PART_CONTEXT is that the code is already written and available for interfacing PART and GI.

The PART_CONTEXT has the entity callback functions to the PART, so the RENDERING_MANAGER gets notified of entity events, such as entity creation, deletion, updating, and rollback, etc. When an entity is added to the PART, it gets passed to the PART_CONTEXT, which in turn passes it on to all of its rendering contexts and views. PART_CONTEXT maintains a flag regarding whether or not to display entities from the PART. All api_pm functions should be thought of as requiring the use of the PART_CONTEXT class.

When using PART and GI, if the PART_CONTEXT is not used, the application must establish its own entity callbacks and functionality to handle start and stop entity creation, start and stop entity modification, etc. The ACIS Microsoft Foundation Class Component uses the PART and RENDERING_MANAGER, but does not use PART_CONTEXT. If PART and the rendering manager are not used, the application has the option to implement a more intelligent layering system, but will have to develop that code again.

[Top]