Relative

If an object specification does not start with a backslash, the ITP/MDK Repository will look for the object in a number of folders that were specified during project configuration. Together, these folders mold the so-called search path. Text Blocks, Forms, and Views all have their own search paths that can be configured on the Runtime tab of the project configuration dialog. Field Sets do not need search paths, as the name of a Field Set is unique within a project.

The ITP/MDK Repository looks for the object in each folder in the order that they are given in the search path. If the object reference also includes folder names, they are considered to be subfolders of the folder in the search path. Searching ends when an object is found with the proper name and an applicable revision (see below). This object is returned and used.

For example, if the search path for Text Blocks in a project is, Correspondence > Correspondence\Salutations > General the Text Block inserted by the model statement TEXTBLOCK NAME "dear mr mrs" will first be sought in the folder Correspondence, then in Correspondence\Salutation and finally in General.

The Text Block 'normal closing' inserted by TEXTBLOCK NAME "closings\normal closing" is sought for in Correspondence\closings, in Correspondence\Salutations\closings and finally in General\closings. In both cases, the Text Block that is found first is returned. If it is not found in any of these folders, the ITP/MDK Repository will look for it in the same way in the Libraries attached to the project. When looking in a library, the search path configured for that library is used.

When a folder is added to the search path, only that folder itself is searched. Sub-folders are not included in the search. You can either add the sub-folders to the search path, or add the sub-folder name to the insert statement.

For example, assume that "folder" is present in the search path, but its sub-folder "subfolder" isn't. The Text Block "text block" resides in "subfolder". This Text Block will not be found if it is inserted with TEXTBLOCK NAME "text block", as "subfolder" is not searched. However, if you insert the Text Block with TEXTBLOCK NAME "subfolder\text block", it will be found.

Applicable revisions

The ITP/MDK Repository not only looks for an object with the proper name, but also with an applicable revision. The first object on the search path with an applicable revision is returned. For model run outside of the ITP/MDK Repository (e.g. production runs), the object must have a [published] revision to be found.

For example, assume you have a Text Block "Customer Details" both in the Text Block folder "folder1" and in Text Block folder "folder2", where "folder1" precedes "folder2" in the search path. A model looking for the Text Block "Customer Details" will get the Text Block residing in "folder1," provided that this Text Block has a [published] revision. If not, searching will continue to "folder2," and the Text Block residing there will be retrieved - again only if it has a [published] revision.

Note

If the ITP/MDK Repository installation is upgraded from a version older than 3.5.10, by default the compatibility option "Handle Accepted revisions as Published" will be turned on. In this case, the status [accepted] takes over the role of the [published] status. For more information refer to the section Revisions used for production runs.

Model runs started from within the ITP/MDK Repository (test runs) only require a [current] revision to exist for an object to be found, or an [in development] revision for objects locked by the user running the model.

Libraries

When looking for the object in the search path of the project does not succeed, the ITP/MDK Repository will continue looking for it in the project's libraries. It will visit the libraries in the order they are configured in the project, and use the search path of the library to find the object.

Starting with ITP/MDK Repository 3.5.3, an option is present to change the library search path behavior. The 'Allow selection of folders in libraries' will cause the ITP/MDK Repository to skip the search paths in the library when looking for dynamic objects. Instead, it allows you to include folders of libraries in the search path of the project itself. This way, it is possible to better control the order of places where dynamic objects are sought.