Not a member? Join Now
Problems signing in? Check here
MicroStation V8 offers new functions for workspace configuration using variables. It is now possible to perform an action based upon the value of a variable.
June 24, 2002 - Workspace configuration files offer both the administrator and user a means to control how MicroStation initializes and looks for information. Using command line switches, variable definition references, pre-processor directives and operators can ensure that MicroStation locates the correct configuration files, defines configuration variables and acts upon these definitions using conditional processing techniques.
Most people who have modified and/or created configuration files in the past have used these techniques to perform such varying tasks as re-locate workspaces to their network, add variable definitions based upon PCF and UCF, or perform an action based upon whether a variable exists or is defined. MicroStation V8 gives you the ability to perform an action based upon the value of a variable.
The newest version of BMAKE supports expressions in pre-processing. Through the use of the constant expressions, %if and %elif, integer constants (in decimal), string or character constants can be compared against a variable definition. Expressions can use the list of operators shown below to act upon constant values, exit codes from commands, strings, characters, macros and file-system paths.
String or Char Constants
string or char concatenation
same string or char
different string or char
less than or equal to
greater than or equal to
You may recognize a number of these operators, as they have been used in configuration files in the past. Let's take a look at how some of the operators have been used so we can better set the stage for how they are used in conjunction with constant expressions.
The example below is a snippet from the main configuration file of MicroStation V8, msconfig.cfg. The syntax is defining the value of _USTN_USERCFG based upon whether certain conditions are met.
%if defined (_BENTLEYREDLINE) || defined (_BENTLEYVIEW)
_USTN_USERNAME : viewonly
%elif defined (_MSGEOOUTLOOK)
_USTN_USERNAME : gouser
%elif defined (_PRJREVIEW)
_USTN_USERNAME : sketch
_USTN_USERNAME : untitled
_USTN_USERCFG : $(_USTN_USER)$(_USTN_USERNAME).ucf
Notice that the first line is using the operator for Logical Or ( || ). This line determines whether either Bentley Redline or Bentley View is installed on the workstation. Should either be installed, hence one of the Or conditions is met, the value of _USTN_USERNAME is conditionally defined as viewonly. Should none of the pre-processor directives produce a true result, the value of_USTN_USERNAME is conditionally defined as untitled.
The experienced workspace user may notice that there was no mention of the dfltuser.cfg file in relation to _USTN_USERNAME. This was an intentional omission, so it could be pointed out that, unlike previous versions of MicroStation, dfltuser.cfg is not installed but created when MicroStation is initialized. This is much like the behavior of the User Preference File (UPF ) and, as the UPF, should dfltuser.cfg be deleted; it will be re-created the next time MicroStation is initialized.
Now that you have seen how these operators are used within a configuration file using pre-preprocessor directives, use them within a constant expression. Many times administrators will choose to configure MicroStation to define the UCF based upon the system environment variable USERNAME. This can become one piece of a roaming profile that will in effect follow users to any workstation on which they login.
Previous to the introduction of constant expression processing, the administrator was unable to act upon the value of USERNAME and could only use that information as a means by which to set other variables' definitions. Referring to the example from msconfig.cfg, examine the last line in which the value of _USTN_USERCFG is being conditionally defined. In the syntax below, you can see that the value of _USTN_USERNAME is critical to which UCF is listed in the MicroStation Manager drop-down box User. Given that, the administrator can accomplish setting this equal to the value of the network login using the following syntax:
_USTN_USERNAME = $(USERNAME)
This is called a Variable Definition Reference. For more information regarding this, see the MicroStation V8 Administrator's Guide.
%if $(USERNAME) == "Administrator"
_USTN_DISPLAYALLCFGVARS = 1>
_USTN_DISPLAYALLCFGVARS = 0
If the syntax above were to be included in a site-level configuration file, for example standards.cfg, the Workspace Configuration Dialog would only display the entire list of configuration variables if both _USTN_USERNAME = $(USERNAME)and the administrator had logged onto the workstation.
Another interesting and useful example of this type of processing can be seen through use of a command line switch. Let's say that the open action for the DGN file type is set to:
"BLOCKED SCRIPTvoid(null);" "-wsMY_FILE=%1" "%1"
This will create a new variable, MY_FILE, which will be equal to the full file specification of the current file. For those of you who have ever read the entire variable list as presented by the Workspace Configuration Dialog, this will seem conspicuously similar to the locked user level variable_DGNFILE. Why would you want to have two variables equal to the same expansion value? The answer should be evident to anyone who has ever tried to use the expanded value of _DGNDIR to set information used as MicroStation is initialized.
Both _DGNFILE and _DGNDIR are set after the file is opened, which means after the configuration files have been processed. So while the Workspace Configuration Dialog may be indicating the correct path to any variable into which they have been used as a Variable Definition Reference, say MS_SYMBRSRC, the RSC files would not have been loaded. This is because no matter at what level MS_SYMBRSRC is defined, the value of either _DGNFILE or _DGNDIR will be undefined.
However, with the use of constant expression processing, as well as use of the -ws command line swich, information such as RSC files can now be loaded based upon the directory of the file which is opened. This only applies when using Windows Explorer; that is, double clicking the file to open.
DEVDIR = $(devdir(MY_FILE))
%if $(DEVDIR) == (path to design file)
MS_SYMBRSRC = (path(s) to RSC files)
%elif $(DEVDIR) == (another path to design file)
The syntax above will allow for specific RSC files to be loaded when a file is opened from Windows Explorer. In addition, this will only load the RSC files if MicroStation was not already initialized. The reason for this is that MicroStation loads the RSC files as it is opened. Once opened, new RSC files cannot be processed.
Constant expression processing is a powerful addition to configuration file/variable processing. Hopefully the above examples, coupled with specific needs and creativity, will spur some innovative and powerful uses.
Can someone describe what the following does: "BLOCKED SCRIPTvoid(null);" ? Does this stop normal configuration script processing and replace with the following only? "-wsMY_FILE=%1" "%1"