Mechanical Modeler

Working with Providers
 

How to customize UI behaviors in applicative containers
Technical Article

Abstract

Some specific features, like Extension Features[1], are designed to be instantiated in Applicative Containers. However, those containers are quite restraint in front of CATPrtCont.

This article is going to talk about a way to extend several CATPrtCont's mechanisms to Applicative Container, using Providers.

To take full advantage of this article, it may be interesting to get more precision about Applicative Container, referring to the "Creating Features in an Applicative Container" article [2].


What are Providers?

    Providers are used to extend behaviors (normally restricted to CATPrtCont) on Applicative Containers.
This technology, normally used in Product case, can be extended in Part case.

A provider is a component (in Object Modeler meaning) which implements an interface whose aim is to retrieve the features of a container.
It is dedicated to a unique applicative container.

Each interface implemented by a provider (and relying to the provider mechanism) is linked to a behavior in the V5 application. This table below lists all the available behaviors in the context of the MechanicalPart.

Tab.1 Available Behavior for MechanicalPart Context
Behavior Interface activated on the feature Interface Provider
Update Mechanism CATIBuild CATIUpdateProvider
Visualization in Spec Tree CATINavigateObject CATINavigateProvider
3D Visualization CATI3DGeoVisu CATI3DVisuProvider
Knowledge Parameter CATIParmPublisher CATIParmProvider

Providers are managed by a "Provider Manager" (CATIProviders) set on the document and retrieved during the Applicative Container's initialization (CATInit::Init ) .

Please note that applicative containers designed for extension are automatically loaded and initialized on the open of an extended part; which is not the case for "traditional" applicative container. (For traditional applicative container, you have to load it manually on opening the Part - For example when you open your dedicated Workshop).

[Top]

Provider Management in Mechanical Part Context

    Provider Managers (CATIProviders)  are only supported by the Mechanical Part.
This means that all extended behaviors, or provided Mechanisms, are linked to MechanicalPart Feature.

    For instance, Update Mechanism, which is extended to applicative container implementing CATIUpdateProvider, will only start updating entirely the MechanicalPart.

Let's take the example of an Extension Feature extending a CombinedCurve instance. This extension will only be updated updating the Mechanical Part! (Local Update on Extended Combined Curve will not dispatch Update to its extension).

Let's take another example...For instance, CATINavigateProvider's implementation.
This provided mechanism will make your applicative features displayable below the CATPart node in the SpecTree. (C.f. Table below)

Result of CATINavigateProvider implemented on an applicative container containing the instance "Mmr3DDataExtension.1"

As a consequence, MechanicalPart can be seen as a "meeting point" between CATPrtCont and applicative containers.

[Top]

Provider Mechanism - How does it work?

[Top]


In Short

    Provider mechanism is one way to extend some CATPrtCont's behaviors (Update, f(x), Visualization in SpecTree and in 3D) to applicative containers.
It is currently set on MechanicalPart context. This means that the "working object" will always represent the MechanicalPart; which links all behaviors to MechanicalPart Feature.

The Provider Mechanism is set during the initialization of applicative container, retrieving the Provider Manager and declaring all the providers needed.

[Top]


References

[1] Working With Extension Feature in Mechanical Modeler
[2] Integrating a New Mechanical Feature in V5
[3] CAAUseCase - Extending a Mechanical Feature using Extension Feature and Providers
[Top]

History

Version: 1 [Feb 2007] Document created
[Top]

Copyright © 1999-2007, Dassault Systèmes. All rights reserved.