Mechanical Modeler |
Working with Providers
How to customize UI behaviors in applicative containers |
|
Technical Article |
AbstractSome 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]. |
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.
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 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]
This implementation is done on components (in Object
Modeler meaning) keeping in mind the
specific context of Mechanical Part.
You can create a unique provider which implements all the requested interfaces, or
you can create as many classes as interfaces. In the use case CAAMmr3DDataExtension
[3] we decided to create 4 components
- one for each interfaces.
As said above, you have to take into account "the specific context of
Mechanical Part" in those implementations.
Let's take the example of CAAMmrDataExtensionContNavigateProvider
implementation below to explain this.
... CATImplementClass(CAAMmrDataExtensionContNavigateProvider, Implementation, CATINavigateProvider, CATNULL); CATImplementBOA(CATINavigateProvider, CAAMmrDataExtensionContNavigateProvider); ... HRESULT CAAMmrDataExtensionContNavigateProvider::GetChildren(CATBaseUnknown * iObj , CATListPtrCATBaseUnknown ** oListChildren) { ... |
"The specific context of Mechanical Part" means that, currently,
iObj can only represent the MechanicalPart.
This is primordial to keep in mind because this fact conditions all the
Provider implementation!
[Top]
Providers make a sort of continuity between
Applicative container and CATPrtCont for behaviors listed in
the first part of this article.
Provider mechanism is initialized during the initialization of the
applicative container. (i.e. during the CATIInit implementation on
the applicative container)
In this implementation (an example can be found in the UseCase [3]),
we first retrieve the Provider Manager (CATIProvider)
Then, we declare all Providers (i.e all component in Object Modeler meaning)
which have to be taken into account on the applicative container.
... void CAAxxxxx::Init (CATBoolean iDestroyExistingData) { CATILinkableObject *piLinkableOnCont = NULL; HRESULT rc = this->QueryInterface(IID_CATILinkableObject,(void**) &piLinkableOnCont); ... CATDocument *pDoc = piLinkableOnCont -> GetDocument(); CATIProviders *piProvidersOnDocument = NULL; rc = pDoc -> QueryInterface(IID_CATIProviders,(void**) &piProvidersOnDocument); CATMyNavigateProvider *pAppliContNavProvider = new CATMyNavigateProvider (); rc = piProvidersOnDocument -> AddProvider (IID_CATINavigateProvider,pAppliContNavProvider); ... |
As you can see, in the example above, we retrieve a pointer to CATIProvider and we add a CATMyNavigateProvider ,which is a kind of CATINavigateProvider, to this "Provider Manager" .
[Top]
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]
[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] |
Version: 1 [Feb 2007] | Document created |
[Top] |
Copyright © 1999-2007, Dassault Systèmes. All rights reserved.