3D PLM Enterprise Architecture |
User Interface - Frame |
Search OverviewHow to search objects in V5 documents |
Technical Article |
AbstractThis article shows how to search objects in a V5 document using the Search API. |
The Edit/Search interactive command enables you to look for objects in the current V5 document. This command uses an API detailed in this article and which is located in the InteractiveInterfaces framework. It is significant to say that this API offers more possibilities than the command itself.
The aim is to look for elements inside a document that match a criterion or a combination of criteria. The process is as follows: a criterion and a scope of search (called the context) are defined and fed into the search engine.
For the criteria, detailed in the Criteria Definition section, two cases can be distinguished:
In fact there is a third category of criterion, the combination criterion. It enables to compose criteria through logical operations to create only one criterion to set as parameter of the search engine.
The architecture of the API is based on the components [1]. A criterion is a component, the context is a component and a component will be created to launch a query. This is explained in the Mechanism Based on Components and Interfaces section.
At the end of this article, there is a section about the Knowledge. The Workbench, Package, Type and Attribute section defines briefly the notions of workbenches, package, type and attribute, and details how to retrieve these objects.
To be complete, it should be specified that there is a use case entitled "Creating Search Queries" [2]. Through some examples, it shows how to create and launch queries, and it gives you some tips not detailed here.
In this section, all the criteria will be described. In fact, the following questions will be answered each time:
This picture shows the General tag page of the Search command.
The criteria are:
In interactive mode, the criterion is obtained by unchecking the "As displayed in graph" button. It enables to look for objects by their external name. It is the name returned by CATIAlias or CATINavigateObject if CATIAlias is not supported. The comparison operator between the value of the criterion and those associated with objects can only be a difference or an equality.
In interactive mode, the criterion is obtained by checking the "As displayed in graph" button. It enables to look for objects by the name displayed in the specification tree. It is the name returned by CATINavigateObject. The comparison operator between the value of the criterion and those associated with objects can only be a difference on an equality.
The other criteria imply only objects implementing the CATIVisProperties interface [3].
The criterion is based on the object's color. If an object has several color (a color for its different sub-elements), the color of the geometry displayed in the Graphic Properties toolbar will be used as a reference for comparison. Refer to the article "Graphical Properties" [3] for more details about the choice of the geometry used in the graphic toolbar. The comparison operator between the value of the criterion and those associated with objects can only be a difference on an equality.
The criterion is based on the visibility state of an object. The comparison operator between the value of the criterion and those associated with objects can only be a difference on an equality.
The criterion is based on the layer. The comparison operator between the value of the criterion and those associated with objects can be anything (equality, difference , superior, inferior, superior or equal, inferior or equal).
The criterion is based on the line thickness. It only applies to linear
objects (CATVPLine
geometry but not CATVPEdge
[3]).
All the comparison signs are accepted.
The criterion is based on the line type. It only applies to linear objects
(CATVPLine
geometry but not CATVPEdge
[3]).
The comparison operator between the value of the criterion and those
associated with objects can only be a difference on an equality.
This second picture shows the Advanced tab page of the Search command.
The queries available in advanced mode are based on the knowledge infrastructure. An advanced criterion is a logical combination between a type based criterion and eventually an attribute based criterion whose attribute is linked to the designed type. The Package, Type and Attribute section gives you more details about knowledge parameters.
The Type Criterion
This criterion enables you to carry out a search based on a knowledge type (CATIType). The comparison operator between the value of the criterion and those associated with objects can only be a difference on an equality.
The Attribute Criteria
These criteria are based on the knowledge attribute. They are the following:
This refers to any Knowledge attribute that is defined as boolean. The comparison operator between the value of the criterion and those associated with objects can only be a difference on an equality.
This refers to any Knowledge attribute that uses units, like the diameter of a hole, the first length of a pad, and so one. The comparison operator between the value of the criterion and those associated with objects can be anything (equality, difference , superior, inferior, superior or equal, inferior or equal).
This refers to any integer type Knowledge attribute. There are two kinds of criterion: with one comparison value or with a range of values comparison. In the first case, the comparison operator can be anything, and in the second case the comparison operator can be only a difference (the value is outside the range) or an equality (inside the range).
This refers to any a finite list of values Knowledge attribute. The comparison operator between the value of the criterion and those associated with objects can only be a difference on an equality.
This refers to any real type Knowledge attribute. There are two kinds of criterion: with one comparison value or with a range of values comparison. In the first case, the comparison operator can be anything, and in the second case the comparison operator can be only a difference (the value is outside the range) or an equality (inside the range).
This refers to any string type Knowledge attribute. The comparison operator between the value of the criterion and those associated with objects can only be a difference on an equality.
This criterion has to be used to look for objects that have a user-defined type attribute. The authorized comparison operators sign values depend on the attribute's type (boolean, dimensioned, integer, listing, real or string).
A query is composed of one criterion and one context. But a criterion can be a combination of elementary criteria. There are three kind of combination:
And : The found element should be available for the two criteria,
Or : The found element should be available for at least one criterion,
Except : The found element should be available for the first criterion but not for the second.
These three logical combinations are consequently a criterion. This criterion has two criteria as parameters for the logical operation.
About the criteria order
If the And and Or logical operations are commutative operations, the order for the parameter is important:
Between a type criterion and an attribute criterion, the type criterion must be the first operand,
For an And operation, the most discriminant criteria should be the first operand,
For an Or operation, the least discriminant criteria should be the first operand.
[Top]
A search query enables you to look for objects in a V5 document. Several aspects of a query are explained here under.
A query is composed of a criterion and a context. The context defines the limits to look for objects.This is important: useful to decrease the research time and to define the scope of the research.The search into the document is based on the specification tree representation. There exist six types of scope:
To look for objects located anywhere in the document.
To look for objects located between the current UI-Active object [4] (called top object) and the next UI-Activable objects located below this top object (called bottom objects). Objects located under those UI-activable objects are not taken into account. The top object and all bottom objects are included in the search.
If the UI-active object is UI-Active Object 1.1
(the
underlined object) all the red and in italic font elements in the above
diagram are taken into account during the search process.
To look for objects located from the current UI-Active object [4] (called top object) to the very bottom of the specification tree for this branch. The top object is included in the search process.
If the UI-active object is UI-Active Object 1.1
(the
underlined object) all the red and in italic font elements in the above
diagram are taken into account during the search process.
To look for objects located in the current set of objects of the editor ( CATCSO [4] ) as well as other objects located underneath in the specification tree.
To look for objects located on the same specification tree level as a reference object. This scope is not possible in the Search command.
To look for objects visible (fully or not) in the current active window. This context won't take into account elements not activated, not represented (features used to build other features that appear in the specification tree but not in 3D), not in the current active filter, not in the current mask... and when the 2D mode is activated elements not in the active plane are excluded from the search result too. Caution: this scope must not be used in a batch. The result would be unpredictable.
In an interactive session you can create queries through the dialog objects (such as combo boxes) of the Search command. But in the Advanced tab page, see Fig.2, you can also enter a string to formulate a criterion. Imagine you enter the "Couleur='Base 25' & Trait=plein" text as follows:
If you are in a French session, this query will be successfully analyzed and
processed. But the same query in a none English session is not valid. This is
why it is important to use the transformat format, a session language
independent format. If you now enter the following text, Color='(255,0,0)'
& dashed=1)
, the query will be valid whatever the language session.
To interactively translate a query from the NLS format to the transformat format, you record a macro command on a Search command based scenario with the appropriate query.
Here is the macro file:
Language="VBSCRIPT" Sub CATMain() Set partDocument1 = CATIA.ActiveDocument Set selection1 = partDocument1.Selection selection1.Search "(Color='(255,0,0)' & Dashed=1),all" End Sub |
where :
(Color='(255,0,0)' & Dashed=1),all
is the query in the
transformat format. (Color='(255,0,0)' & Dashed=1)
is the criterion all
is the context.This macro file gives you also the internal name for knowledge types and attributes. These pieces of information are mandatory to create any advanced criterion.
Here is an example of scenario:
Language="VBSCRIPT" Sub CATMain() Dim partDocument1 As Document Set partDocument1 = CATIA.ActiveDocument Dim selection1 As Selection Set selection1 = partDocument1.Selection selection1.Search "CATGmoSearch.GSMScaling.NameInGraph=CAAName,all" End Sub |
Where :
CATGmoSearch
is the internal name of a category
(also named workbench in the Search command) which is a set of
packages whose external name (NLS name) is Generative Shape
Design.
GSMScaling
is the internal name for a knowledge type whose
the NLS name is Scaling
NameInGraph
is the internal name for a knowledge
attribute whose NLS name is Name in Graph
From a string (NLS or Transformat) it is possible to (re-)create a query. Thus you can store queries in a setting file using the transformat format and then fully reuse this information in an other session whatever the language used.
[Top]
Criteria, context and search engine are components [1]. A component is identifiable through a CLSID and instantiable thanks to the CATCreateInstance global function [5].
... #include "CATIniSearchEngineComponent.h" ... CATIIniSearchEngine* pISearchEngine=NULL; HRESULT rc = ::CATCreateInstance(CLSID_CATIniSearchEngineComponent, NULL, 0, IID_CATIIniSearchEngine, (void**)&pISearchEngine); ... |
The CATIniSearchEngineComponent header file contains the definition of
the CLSID associated with the Search Engine component. This CLSID is CLSID_CATIniSearchEngineComponent.
For each object of the Search mechanism, the CLSID of the component and its specific interface will be given in the following array. All the useful CLSID and interfaces are located in the InteractiveInterfaces framework
At first the General criteria:
General Criterion | Component CLSID | Dedicated Interface |
Color | CLSID_CATIniSearchColorCriterion | CATIIniSearchColorCriterion |
Name | CLSID_CATIniSearchNameCriterion | CATIIniSearchNameCriterion |
GraphName | CLSID_CATIniSearchGraphNameCriterion | CATIIniSearchGraphNameCriterion |
Line type | CLSID_CATIniSearchDashedCriterion | CATIIniSearchDashedCriterion |
Line thickness | CLSID_CATIniSearchWeightCriterion | CATIIniSearchWeightCriterion |
Layer | CLSID_CATIniSearchLayerCriterion | CATIIniSearchLayerCriterion |
Visibility | CLSID_CATIniSearchVisibilityCriterion | CATIIniSearchVisibilityCriterion |
V4 Model | CLSID_CATIniSearchV4ModelCriterion | CATIIniSearchV4ModelCriterion |
Then, the advanced criteria.
Advanced Criterion | Component CLSID | Dedicated Interface |
Boolean | CLSID_CATIniSearchBooleanCriterion | CATIIniSearchBooleanCriterion |
Integer | CLSID_CATIniSearchIntegerCriterion | CATIIniSearchIntegerCriterion |
Real | CLSID_CATIniSearchRealCriterion | CATIIniSearchRealCriterion |
Listing | CLSID_CATIniSearchListingCriterion | CATIIniSearchListingCriterion |
Dimension | CLSID_CATIniSearchDimensionCriterion | CATIIniSearchDimensionCriterion |
String | CLSID_CATIniSearchStringCriterion | CATIIniSearchStringCriterion |
User | CLSID_CATIniSearchUserCriterion | CATIIniSearchUserCriterion |
Type | CLSID_CATIniSearchTypeCriterion | CATIIniSearchTypeCriterion |
Finally, the combination criteria.
Combination Criterion | Component CLSID | Dedicated Interface |
And | CLSID_CATIniSearchAndCriterion | CATIIniSearchAndCriterion |
Or | CLSID_CATIniSearchOrCriterion | CATIIniSearchOrCriterion |
Except | CLSID_CATIniSearchExceptCriterion | CATIIniSearchExceptCriterion |
Interfaces Architecture
In this diagram you can note that:
The last three components are the following:
Type | Componant CLSID | Dedicated Interface |
Context | CLSID_CATIniSearchContext | CATIIniSearchContext |
Search Engine | CLSID_CATIniSearchSearchEngine | CATIIniSearchEngine |
Services | CLSID_CATIniSearchServices | CATIIniSearchServices |
In the advanced queries, you should be familiar with some knowledge objects: workbench, packages, type and attribute. To sum up a workbench is a group of packages, which is itself a group of types, and a type is a group of attributes. The section begins to explain the package notion, and ends by explanation about workbench.
A package defines a set of types. All the types are "stored"
in a dictionary. To retrieve a smart pointer on the unique type dictionary, you
can use the static GetTypeDictionary
method of the CATGlobalFunction
class.
... CATITypeDictionary_var pITypeDictionary; pITypeDictionary = CATGlobalFunctions::GetTypeDictionary(); ... |
A type is handled through a CATIType interface. To retrieve a pointer
on a type, you can use the FindTypeInPackage
method on the CATITypeDictionary
interface pointer.
... CATIType_var spITypeToFind; CATUnicodeString InternalTypeName ="Hole"; CATUnicodeString PackageName = "PartDesign" ; rc = pITypeDictionary ->FindTypeInPackage(InternalTypeName, PackageName , spITypeToFind); ... |
The first two arguments of this method respectively are the internal name of a type and its package . The following scenario gives you the means to know the list of packages and for each of them the list of types and their associated attributes.
The following dialog box appears:
The first column displays the list of packages, the second column displays the type contained by the selected package, and the last column displays the list of attributes for the selected type. All the names are internal name, in other words language independent.
Internal name versus NLS name
UserName
on the CATIType interface
provides the NLS name of a typeA workbench, knowledge sense, groups together packages. It is without relationship with the workbench of a V5 document [4].
The workbench is only used for the Search Mechanism. The following picture shows some of them in the Search command.
In the Search command, you must choose a workbench to launch a query. The workbench enables us to provide a limited list of types (second combo). The first combo could have been a package name, but the notion of package is too short. A workbench groups together a "logical" set of types.
The workbench entity is optional for the Search API. To create a type
criterion, only a CATIType interface pointer is mandatory. Lets us see
the SetParameters
method of the CATIIniSearchTypeCriterion
interface.
... virtual HRESULT SetParameters (const CATIType* iSearchedType, CATIniSearchEnumeration::Comparison iOperatingSign, CATUnicodeString iWorkbenchInternalName="") = 0; ... |
iWorkbenchInternalName
is optional, you can set an empty string.
Specifying the name of the workbench can be useful if you want display the query
and inform your end users that the type provide from such or such workbench.
iWorkbenchInternalName
is an internal name, it is not the NLS
name displayed by the Search command. To retrieve the internal name from the NLS
name, follow the scenario which uses a VB macro.
This article give you an overview of the Search API. It describes :
[Top]
[1] | Using Components |
[2] | Creating Search Queries |
[3] | Graphical Properties |
[4] | Application Frame Overview |
[5] | Instantiating a Component Using its CLSID |
[Top] |
Version: 1 [May 2003] | Document created |
[Top] |
Copyright © 2003, Dassault Systèmes. All rights reserved.