| Product(s): | AECOsim Building Designer | ||
| Version(s): | CONNECT Edition (10.0.0.154) | ||
| Environment: | N/A | ||
| Area: | Workspace | ||
| Subarea: | Configuration |
In CONNECT Edition (hereafter referred to as CONNECT), there have been numerous changes to the way Configuration Files are organized and processed. This document provides information regarding these changes and is intended to be CONNECT Edition specific and applicable to all Bentley applications based on the CONNECT Edition PowerPlatform. It also assumes you have a preexisting knowledge of configuration file concepts and a familiarity with how they were used in V8i.
In V8i, the overall usage of Configuration Files and Configuration Variables was referred to as Workspaces. That overall usage is referred to as the Configuration in CONNECT.
The term "WorkSpace" now has a different meaning, see 5. below.
In V8i, the grouping of Configuration Files and Configuration Variables that were used across an entire organization was referred to as the “Site” level. In CONNECT, it is referred to as the “Organization” level.
In V8i, a grouping of files and associated data was referred to as a “Project”. That terminology has been problematic, because organizations use the term Project for a business purpose that is rarely precisely correlated to the data grouping in Bentley Applications. Therefore, that grouping is now referred to as a “WorkSet”. For example, the Configuration Variable level formerly known as Project is now the WorkSet level.
In V8i, Projects were organized by “User”. Selecting a different User had the effect of changing the list of Projects that were available, and also changing the User Preference (.upf) file and User Configuration (.ucf) file in use. In CONNECT, selection of User has been removed from the user interface. Each CONNECT user has their own personal .upf file and .ucf file, associated with their Windows login, so that configuration variables that they set and user preferences that they select are not affected by the WorkSpace or WorkSet they are working on.
In V8i, the default delivery directory was to a root directory that contained the Workspace, and Documentation subdirectories. In keeping with the terminology change discussed above, the Workspace directory has been renamed to Configuration. The V8i WorkSpace directory included Bentley-provided system data in the System subdirectory. That was a disadvantage because some of that data is version specific, so in CONNECT, there is no Configuration\System directory. Its contents have been moved into a subdirectory within the Program directory typically under Program Files\Bentley\<ApplicationName>.
In V8i, there were 5 Configuration Levels, organized from lowest to highest priority as shown below. Configuration Variables defined at higher levels override definitions at lower levels:
0 - System
1 - Application
2 - Site
3 - Project
4 - User
In a V8i Configuration File, the level at which Configuration Variables were defined was set using the %level directive, specifying one of the numbers in the left column above (e.g. %level 1). An alternative was to put the level number at which Configuration Files were to be processed in the %include statement.
In CONNECT, there are 7 Configuration Levels. From lowest to highest priority they are:
0 - System
1 - Application
2 - Organization
3 - WorkSpace
4 - WorkSet
5 - Role
6 - User
In a Configuration File, the level is still set using the %level directive, but now the argument is one of the text values in the right column instead of the number (e.g. %level Application). That improves readability of configuration files. You can still specify a number, but a warning is generated because it is an indication that you might be processing a pre-CONNECT configuration file, and the Configuration Level number might no longer be correct. Most of the time, the %level directives (or level settings in %include statements) are in Bentley-delivered configuration files that sequence inclusion of user-authored configuration files, rather than in user-authored configuration files. However, advanced users may have used %level directives, and thus might encounter the warning.
The two additional levels in the CONNECT configuration, WorkSpace and Role, are discussed below.
In CONNECT, a “WorkSpace” is a container grouping WorkSets, standards files, and associated Configuration Files that are used in a broad context. Different user organizations will have different uses for the “WorkSpace” grouping mechanism. Engineering and Architectural firms might use a separate WorkSpace for each of their clients. Asset owners are likely to use a separate WorkSpace for each asset or department. For that reason, the label that appears for WorkSpace in the CONNECT user interface can be set by a configuration variable. That is done by specifying the Configuration Variable _USTN_WORKSPACELABEL in the WorkSpaceSetup.cfg file in the Configuration subdirectory. The default value is the neutral “WorkSpace”.
For those familiar with V8i, there is some parallel between WorkSpaces and the “User” concept in V8i, in that the User Configuration File was used to filter the displayed Projects list. However, WorkSpaces are better suited to typical user organization workflows because they appear at the correct level in the hierarchy of Configuration Levels, and because they do not affect user-specific settings.
Organisations that have used the V8i "User" level to select configurations for specific groups, e.g. clients. major projects, etc. can achieve similar granularity by creating WorkSpaces for each of these groups.
A frequent enhancement request has been to add a Configuration Level that allows standards and certain program behavior to be controlled based on the role or discipline of an individual user. CONNECT provides this additional Configuration Level, but leaves it to the user organization to determine how to identify the role of individual users. To use this feature, the Configuration Variable _USTN_ROLECFG is set to the full file name of a Configuration File that contains the role-specific Configuration Variable settings. That can be accomplished in any of the following ways:
setting a system environment variable at login time,
conditional tests in WorkSet or WorkSpace configuration files,
setting the configuration variable in the Configuration dialog,
some other mechanism devised by the system administrator.
The _USTN_ROLECFG Configuration File is processed after the WorkSpace, WorkSet and User Configuration Files have been processed, to allow any of them to specify _USTN_ROLECFG.
Bentley applications, based on the shared PowerPlatform, define Configuration Variables at the System and Application levels in Configuration Files that are delivered with the product. Administrators generally make changes at the Organization, WorkSpace, WorkSet, and Role levels, in user-supplied Configuration Files. Each Bentley application provides template Configuration Files that can be used as a starting point for those Configuration Files.
Configuration Variables are organized into Framework Configuration Variables, which start with the “_USTN_” prefix, and Operational Configuration Variables, most of which start with the “MS_” prefix. In general, the Framework Configuration Variables are used in Configuration Files, while Operational Configuration Variables are used to direct program flow within the application. A few of the Framework Configuration Variables are determined by the application installation directory. Other Framework Configuration Variables default to locations relative to the installation directory, but can be (and some of them are expected to be) changed in configuration files provided by the user.
Configuration File processing can be regarded as interpreting a simple program, part of which is provided by System Configuration Files, which should not be modified by the user, and part of which is provided by Configuration Files that are intended to be user modified. All configuration files are simple text files that can be examined (and modified, in the case of user-modifiable Configuration Files) with any text editor.
The system Configuration Files are located in the <ApplicationName>/config installation directory, while user-modifiable Configuration Files are in the Configuration installation directory or other user-specified directories. User-modifiable Configuration Files are included into the Configuration File processing flow at appropriate times by the System Configuration Files.
Section 9 provides a “walk through” of the processing of Configuration Files, and identifies the touch points where user-modifiable Configuration Files can specify directories and application behavior.
An essential aid to understanding Configuration File processing is the command line argument “-debug”. That instructs the Bentley application to write out a text file that contains the history of how every Configuration Files was processed, and to open that file in whatever editor that your Windows system has configured to handle text files (usually Notepad). When you close Notepad, the parent the Bentley application closes also.
Within your Bentley application, you can also see the current values of all Configuration Variables using the new “SHOW CONFIGURATION” command. That also opens Notepad with the current Configuration Variables.
Configuration files consist of statements of four types:
Flow Directives that control the flow through Configuration Files.
Variable Directives that control certain aspects of Configuration Variables
Assignment statements that set the value of Configuration Variables.
Operators and expressions that manipulate strings or Configuration Variables to yield results that can be used in directives or assignments
Configuration Variables are often defined in terms of other Configuration Variables. This can be done in two different ways:
When plain parentheses are used, as in $(<CfgVarName>), the expression is stored verbatim in the Configuration Variable definition and evaluated later, when the value of the Configuration Variable is eventually needed during program execution. This form is much more flexible, since the definition can be set using other Configuration Variables even if they have not yet been defined. It is thus more commonly used.
When curly braces are used, as in ${<CfgVarName>}, the value of CfgVarName is evaluated immediately, while the configuration file itself is being processed. Therefore, the Configuration Variable used in the expression must be previously defined.
The following flow directives are supported:
|
Flow Directive |
Syntax |
Definition |
|
%include |
%include <filespec>
%include <filespec> level <levelspec> |
Includes one or more Configuration Files before proceeding with the next line in this Configuration File. <filespec> can specify a single file, or can include wildcard characters to include many files. <filespec> can contain Configuration Variables. Example: %include $(_USTN_WORKSPACECFG) The include directive can include a Configuration Variable level at which the assignments in the included file are applied (until another level directive is encountered). Example: %include $(_USTN_ROLECFG) level Role |
|
%if |
%if <expression> |
If <expression> evaluates to true, continue on the next line, otherwise skip to the matching %else, %elif, or %endif statement. See Expressions and Operators for the syntax of <expression>. Example: %if $(PHASE)==”Final” |
|
%ifdef |
%ifdef <cfgvar> |
If <cfgvar> is defined, continue on the next line, otherwise skip to the matching %else, %elif, or %endif statement. Example: %ifdef _USTN_ROLECFG |
|
%ifndef |
%ifndef <cfgvar> |
If <cfgvar> is not defined, continue on the next line, otherwise skip to the matching %else, %elif, or %endif statement. Example: %ifndef MS_DEF |
|
%else |
%else |
An %if, %ifdef, or %ifndef that evaluates to false continues at the line following a matched %else statement, if there is one. |
|
%elif |
%elif <expression> |
An %if, %ifdef, or %ifndef that evaluates to false continues by evaluating <expression> at the first matched %elif statement, and then either continues processing at the line following if expression evaluates to true, or skips to the next %elif, %else, or %endif statement. %elif defined (MS_RFDIR) |
|
%endif |
%endif |
The statement that indicates the end of the conditional block for an %if, %ifdef, or %ifndef statement. |
|
%echo |
%echo <message> |
Shows the contents of <message> in MicroStation’s text window and continues processing. Example: %echo $(MS_DEF) |
|
%error |
%error <message> |
Causes processing to stop, reporting the contents of <message> as the error. %error unexpected value |
The following variable directives are supported:
|
Variable Directive |
Syntax |
Definition |
|
%lock |
%lock <cfgvar> |
Locks the Configuration Variable <cfgvar> so that it cannot be changed. |
|
%undef |
%undef <cfgvar> |
Discards the value of the Configuration Variable and sets it to undefined. |
|
%level |
%level <newLevel> |
Specifies the level at which any following Configuration Variable definitions are to be applied. The <newlevel> argument should be one of the following: System Application Organization WorkSpace WorkSet Role User Case is unimportant. |
The following table shows the different ways that a Configuration Variable can be defined.
|
Assignment operator |
Definition |
|
= |
Assign the Configuration Variable at the current level, regardless of whether it is currently defined. Example: MS_SHEETMODELNAME = 2D Sheet |
|
: |
Assign the Configuration Variable at the current level, but only if it not already defined. Example: MS_BACKUP : $(_USTN_OUT) |
|
> |
Appends the operand to the existing definition of the variable, separating the existing value and the operand by semicolons (treating the variable as a path). Example: MS_RFDIR > $(_USTN_WorkSetROOT)Borders/ |
|
< |
Prepends the operand to the existing definition of the variable, separating the existing value and the operand by semicolons (treating the variable as a path). Example: MS_RFDIR < $(_USTN_WorkSetROOT)Borders/ |
|
+ |
Appends the operand to the existing definition of the variable without separator. _USTN_WorkSetDESCR + In Development |
The following table shows operators that can be used in Configuration Variable definitions and how they are interpreted as a Configuration Variable is expanded. In the examples below, assume that $(USTN_WorkSetCFG) is defined as g:/Clients/DeptOfTransportation/WorkSets/Highway131.cfg
|
Operator |
Syntax |
Definition |
|
basename |
basename (<expression>) |
Returns the filename of <expression> without directory or extension. Example: WorkSetNAME = basename (_USTN_WorkSetCFG) gives Highway131 |
|
concat |
concat (<arg1>,<arg2>…) |
Returns the concatenation of the arguments, similar to the + operator, but allows multiple arguments. Example: LIST = concat (CFG1,CFG2,CFG3) |
|
devdir |
devdir (<expression>) |
Returns the device and directory of <expression>, including a trailing directory separator. Example: WorkSetDIR = devdir (_USTN_WorkSetCFG) gives g:\Clients\DeptOfTransportation\WorkSets\ |
|
dev |
dev (<expression>) |
Returns the device (e.g., c:) of <expression>. Example: WorkSetDEV = dev (_USTN_WorkSetCFG) gives g: |
|
dir |
dir (<expression>) |
Returns the directory (without the device) of <expression>. Example: WorkSetDIR = dir (_USTN_WorkSetCFG) gives \Clients\DeptOfTransportation\WorkSets\ |
|
ext |
ext(<expression>) |
Returns the file extension of <expression>. Example: WorkSetEXT = ext (_USTN_WorkSetCFG) gives .cfg |
|
filename |
filename (<expression>) |
Returns the filename and extension of <expression>. Example: WorkSetFILE = filename (_USTN_WorkSetCFG) gives Highway131.cfg |
|
first |
first (<expression>) |
Returns the first portion of an expression (i.e., the part preceding the first semicolon). Example: FIRSTREFDIR = first (MS_RFDIR) |
|
firstdirpiece |
firstdirpiece (<expression>) |
Returns the root directory (without device) of <expression>. Example WorkSetROOT = firstdirpiece ($(_USTN_WorkSetCFG)) gives Clients |
|
lastdirpiece |
lastdirpiece (<expression>) |
Returns the portion of the directory closest to the file in <expression>. Example: WorkSetPAR = lastdirpiece ($(_USTN_WorkSetCFG)) gives WorkSets |
|
noext |
noext (<expression>) |
Returns the full path of <expression>, omitting the extension. WorkSetFILEROOT = noext (_USTN_WorkSetCFG) gives g:\Clients\DeptOfTransportation\WorkSets\Highway131 |
| parentdevdir |
parentdevdir (<expression>) |
Returns the parent directory, including the device, of <expression>. Example: WorkSetPDD = parentdevdir (_USTN_WorkSetCFG) gives g:\Clients\DeptOfTransportation\ |
|
parentdir |
parentdir (<expression>) |
Returns the parent directory, excluding the device, of <expression> WorkSetPD = parentdir (_USTN_WorkSetCFG) gives \Clients\DeptOfTransportation\ |
|
registryread |
registryread (regvar) |
Returns the contents of the registry variable regvar. Example: PWDIR=registryread("HKEY_CURRENT_USER\SOFTWARE\Bentley\ProjectWise\Path") |
Configuration File processing starts with the Configuration File mslocal.cfg. It is a “bootstrap” file with only a few lines – it includes msdir.cfg, another small Configuration File that is generated at install time and identifies the application’s installation directory, and then includes msconfig.cfg, which contains the main “program flow” of Configuration File processing.
You should never modify msconfig.cfg itself (or any of the other configuration files in the program directory). As you will see in the discussion below, there are several well-defined places where msconfig.cfg includes user-modifiable Configuration Files. It is in those user-modifiable Configuration Files that Configuration Variables should be modified to provide all the flexibility necessary to meet your organization’s requirements for data location.
The msconfig.cfg Configuration File begins by setting the _USTN_BENTLEYROOT Configuration Variables and a number of Framework Configuration Variables that point to directories where program data is delivered. Those are necessary for program operation, but do not define locations for any user data or files. It then includes the system and application Configuration Files that are shipped with the relative Bentley application.
#----------------------------------------------------------------------*/
# Include all the delivered system configuration files.
# These define System level configuration variables.
#----------------------------------------------------------------------
%include $(_USTN_SYSTEM)*.cfg level System
#----------------------------------------------------------------------
# Include the delivered application configuration files.
# These define Application level configuration variables.
#----------------------------------------------------------------------
%include $(_USTN_APPL)*.cfg level Application
The part relevant to setting up a customized Configuration begins where msconfig.cfg defines the _USTN_CONFIGURATION Configuration Variable:
#----------------------------------------------------------------------
# Define the root directory for the Configuration data.
#----------------------------------------------------------------------
_USTN_CONFIGURATION : ${_USTN_BENTLEYROOT}Configuration/
Since the curly braces are used, this is immediately evaluated to the Configuration subdirectory of the installation directory.
By default, many other Configuration Variables are set to subdirectories of the directory defined by _USTN_CONFIGURATION. The definition of those variables (_USTN_ORGANIZATION, _USTNWORKSPACESROOT, _USTNWorkSetSROOT, etc.) follows the definition of _USTN_CONFIGURATION.
The first opportunity for customization of your configuration is where msconfig.cfg includes WorkSpaceSetup.cfg:
%if exists ($(_USTN_CONFIGURATION)WorkSpaceSetup.cfg)
% include $(_USTN_CONFIGURATION)WorkSpaceSetup.cfg
%endif
As you can see WorkSpaceSetup.cfg is located in the Configuration directory of the delivery, and is intended to be customized by users. Here is the contents as it shipped:
#----------------------------------------------------------------------
# WorkSpaceSetup.cfg - Configures WorkSpace for Your Organization
#
# The main function of this configuration file is to set the label that
# your organization wants to use for WorkSpaces. WorkSpaces are the
# grouping mechanism for WorkSets. The label for this level of grouping
# could be Client, Facility, Department, Owner, or whatever you would
# like it to be. The default label is the neutral "WorkSpace". Uncomment
# the definition below, and set it to your preferred label.
#----------------------------------------------------------------------
# _USTN_WORKSPACELABEL : WorkSpace
#----------------------------------------------------------------------
# A second possible use for this configuration file is to redirect the
# root directory where your Organization-wide standards are stored to somewhere
# other than the default. The default is $(_USTN_CONFIGURATION)Organization/.
# It can be changed by redefining _USTN_ORGANIZATION.
#----------------------------------------------------------------------
#----------------------------------------------------------------------
# A third possible use for this configuration file is to redirect the
# root directory where your WorkSpaces are stored to somewhere other
# than the default. The default is $(_USTN_CONFIGURATION)WorkSpaces/.
# It can be changed by redefining _USTN_WORKSPACESROOT.
#----------------------------------------------------------------------
The comments in the file explain its three principle uses – setting the WorkSpace label to the desired value for your organization, and possibly redirecting your organization-wide standards data and/or all of your other WorkSpace data to another location (for example, to a network share). See the “Typical Configuration Scenario” section below for an example of usage.
Upon returning from including WorkSpaceSetup.cfg, msconfig.cfg includes your organization-wide Configuration Files (if any):
#----------------------------------------------------------------------
# Include the Organization specific configuration files.
# The configuration files in the _USTN_ORGANIZATION directory are intended to
# set configuration variables that point to organization-wide standards
# such as level libraries, cell libraries, etc. Those settings can be
# augmented or overridden at the WorkSpace or WorkSet level.
#----------------------------------------------------------------------
%level Organization
%if exists ($(_USTN_ORGANIZATION)*.cfg)
% include $(_USTN_ORGANIZATION)*.cfg
%endif
As delivered, _USTN_ORGANIZATION points to the Configuration\Organization directory, which contains one Configuration File, standards.cfg, which sets Configuration Variables assuming the generic directory structure in the delivery. If you have redirected _USTN_ORGANIZATION, you can either adopt the same directory structure or change it to meet your needs. Since the %include statement above includes all Configuration Files in the _USTN_ORGANIZATION directory, you can call your Configuration File something other than standards.cfg, and you can use more than one Configuration File in that directory if you prefer. They will be included in alphabetical order.
The next step is to include the User Configuration file. The User Configuration file is stored in the preferences directory as Personal.ucf, and stores the individual users preferences and state. It is included here, because the most recently used WorkSpace and WorkSet are stored in the User Configuration file.
The next step in the configuration process is to determine the WorkSpace Configuration File. Each WorkSpace has a Configuration File named <WorkSpaceName>.cfg that must be located in the directory pointed to by _USTN_WORKSPACESROOT. As delivered, _USTN_WORKSPACESROOT is defined as $(_USTN_CONFIGURATION)WorkSpaces/, but that can be changed in the WorkSpaceSetup.cfg file as discussed above.
One and only one WorkSpace Configuration File is processed. There is some logic in msconfig.cfg that determines which WorkSpace Configuration File to load by setting the _USTN_WORKSPACENAME, but that can be ignored for our current purposes – The application is responsible for remembering the most recent WorkSpace name and using it to set _USTN_WORKSPACENAME.
The WorkSpace Configuration File is then included from msconfig.cfg using this construction:
%if defined (_USTN_WORKSPACENAME)
% if exists ($(_USTN_WORKSPACESROOT)$(_USTN_WORKSPACENAME).cfg)
_USTN_WORKSPACECFG = $(_USTN_WORKSPACESROOT)$(_USTN_WORKSPACENAME).cfg
% include $(_USTN_WORKSPACECFG) level WorkSpace
% endif
%endif
User organizations will frequently customize WorkSpace Configuration Files. When a new WorkSpace is created, it starts with a template WorkSpace Configuration File like the following:
#----------------------------------------------------------------------
# WorkSpace.Template - Template for new WorkSpaces
#
# When MicroStation runs, one and only one WorkSpace configuration file
# is chosen and included.
#
# The function of the WorkSpace configuration file is to define the location
# of _USTN_WORKSPACEROOT, _USTN_WORKSPACESTANDARDS, and/or _USTN_WorkSetSROOT
# for this WorkSpace. Those are the root directory, the standards directory,
# and the WorkSets root directory, respectively.
#
# Default locations are defined in msconfig.cfg:
# _USTN_WORKSPACEROOT is $(_USTN_WORKSPACESROOT)$(_USTN_WORKSPACENAME)/
# _USTN_WORKSPACESTANDARDS is defined as $(USTN_WORKSPACEROOT)Standards/
# _USTN_WorkSetSROOT is defined as $(USTN_WORKSPACEROOT)WorkSets/
# If those defaults are acceptable, this file need not make any definitions.
# To move all WorkSpace data to a separate directory (e.g., to a network share)
# _USTN_WORKSPACEROOT can be redefined and the default values retained for
# _USTN_WORKSPACESTANDARDS and _USTN_WorkSetSROOT
#----------------------------------------------------------------------
As you can see, any combination of the WorkSpace root, standards, or WorkSets root directory can be redirected according to the user’s requirements.
The next step in msconfig.cfg is to include any Configuration Files that are stored in the directory pointed to by _USTN_WORKSPACEROOT:
#----------------------------------------------------------------------
# When we get to this point, we have a WorkSpace defined.
# There may be .cfg files within the WorkSpace. Process those here.
#----------------------------------------------------------------------
%if exists ($(_USTN_WORKSPACEROOT)*.cfg)
% include $(_USTN_WORKSPACEROOT)*.cfg level WorkSpace
%endif
These Configuration File(s) are optional, and can contain whatever Configuration Variable definitions that are appropriate in the user’s workflow. Often, no additional Configuration Files are needed and the delivered Example WorkSpace doesn’t have any.
After the WorkSpace Configuration Files have been processed, msconfig.cfg attempts to load one (and only one) WorkSet Configuration File. Each WorkSet within a WorkSpace has a Configuration File named <WorkSetName>.cfg that must be located in the directory pointed to by _USTN_WorkSetSROOT. By default, _USTN_WorkSetSROOT is defined as $(_USTN_WORKSPACEROOT)WorkSets/, but that can be changed in the WorkSet Configuration File as discussed above. The Bentley application is responsible for remembering the most recently used WorkSet, and it sets the _USTN_WorkSetNAME configuration variable accordingly. The WorkSet Configuration File is included like this:
%if exists ($(_USTN_WorkSetCFG))
% include $(_USTN_WorkSetCFG) level WorkSet
%endif
After WorkSet Configuration files have been processed, msconfig.cfg checks to see whether _USTN_ROLECFG has been defined. If it has, the Configuration File that it is defined in _USTN_ROLECFG is processed. As mentioned above, MicroStation has no default for _USTN_ROLECFG – it must be set as a system environment variable or defined in one of the user-modifiable Configuration Files that are processed prior to reaching this part of msconfig.cfg
The final part of msconfig.cfg handles the database configuration file, if that feature is in use.
When msconfig.cfg has been fully processed, all the initial Configuration Variable definitions are complete
Whenever a different WorkSet is selected, the following Configuration Variable actions are taken:
If the WorkSet belongs to a WorkSpace that is different from the WorkSpace to which the currently active WorkSet belongs, all WorkSpace level Configuration Variables are discarded.
All WorkSet level Configuration Variables are discarded.
If the WorkSet belongs to a different WorkSpace, that WorkSpace’s Configuration File(s) are processed.
The WorkSet Configuration Files are processed.
The new WorkSpace and WorkSet are written to the user’s Personal.ucf file.
A different WorkSet can be selected in a number of ways:
From File->Browse, a different WorkSpace/WorkSet can be selected in the File Browser dialog.
From the Start Page (reached using File->Close) a different WorkSpace/WorkSet can be selected either directly or by selecting one of the Recent WorkSets.
In CONNECT, design files have their WorkSpace / WorkSet recorded in their metadata. When a design file with such metadata is opened, and it is from a different WorkSet, the user can opt to change to the WorkSpace / WorkSet recorded in its metadata.
Using the “-WW<WorkSet> command line argument when starting the application.
The following table lists the framework Configuration Variables in CONNECT that are either new or replace Configuration Variables in V8i. In the case of a replacement, the second column lists the V8i Configuration Variable.
|
CONNECT Configuration Variable |
V8i Configuration Variable |
Description |
|
_USTN_CONFIGURATION |
_USTN_WORKSPACEROOT |
Defined to the root directory where user-modifiable Configuration Files are located. |
|
_ USTN_ORGANIZATION |
_ USTN_SITE |
Defined to the root directory where organization-wide standards files are located. |
|
_USTN_WORKSPACESROOT |
|
Defined to the root directory where all WorkSpace Configuration Files are located. |
|
_USTN_WORKSPACEROOT |
|
Defined to the root directory of a particular WorkSpace. |
|
_USTN_WORKSPACESTANDARDS |
|
Defined to the root directory where the Workspace-wide standards files are located. |
|
_USTN_WORKSPACECFG |
|
The Configuration File that corresponds to one particular WorkSpace |
|
_USTN_WorkSetSROOT |
_USTN_PROJECTSROOT, |
Defined to the directory where the WorkSet Configuration files are located. |
|
_USTN_WorkSetROOT |
_USTN_PROJECTDATA
|
Defined to the parent directory of the Standards and data directories for the WorkSet. |
|
_USTN_WorkSetSTANDARDS |
|
Defined to the root directory where WorkSet standards files are located. |
|
_USTN_WorkSetDGNS |
|
Defined to the directory where the WorkSet design files are located. |
|
_USTN_WorkSetCFG |
_USTN_PROJECTCFG |
The Configuration File that corresponds to one particular WorkSet |
V8i used the term Workspace to refer to an organization's networked configuration and resources. In CONNECT Edition, as mentioned above this is now known as a shared Configuration (it may also be referred to as a Custom Configuration to highlight the organization specificity).
The location of your organization's Custom Configuration should be set during the application installation process. This is described in detail in the wiki and blog posts linked from CONNECT Edition - Configuration : Customization Guides.