This Client Server article is republished in its entirety from 2003 for reference purposes.

By Chris Marks, Platform Support Analyst, Bentley Corporate Office
11 August 2003

Are you having problems copying reference elements into your master model? Does the color of your elements change when referenced? Do elements in one reference appear "on top" of elements in another reference? These problems and more can be addressed by manipulating reference preferences.

With the numerous changes to MicroStation's reference system, it is time to revisit this topic of reference preferences with an eye to MicroStation V8.

Color Table

Let's begin with the preference Use Color Table. As stated in the first article, "If disabled (it is enabled by default), MicroStation ignores any color table attached to a reference file and displays the elements in it using the active design file's color table."

Nothing has changed regarding this preference, however, one thing should be mentioned with respect to the configuration variable MS_DEFCTBL.

This variable's functionality lies in replacing the default color table. The important fact to note is that this variable affects only design files that do not contain an attached color table. If a color table was attached at any time in the file's history, the variable will not replace that color table.

For example, if you wish to use the grayscale color table, 256_neg.tbl, in place of color.tbl, you would set MS_DEFCTBL = 256_neg.tbl. Now, when you open any file that uses the default color table you will be using the grayscale table.

The implication is that if you use MS_DEFCTBL to supply the color table to your proposed reference model, you could experience what appear to be inconsistent results when referencing a model from one project to a model in a different project-assuming that MS_DEFCTBL is unique to both PCFs. That is, the Use Color Table preference will not affect the display of the reference model because a color table was not attached but supplied by the variable. The PCF setting for the master model will be used when displaying the reference model's graphics. If, however, you are careful to manage your workflow, this should not be a problem.

The last point to be made when discussing Use Color Table is that when referencing a DWG/DXF file the reference color table will always be used, unless MS_DWGREF_ALLOWMASTERCOLORS = 1 is utilized. This variable defines how MicroStation uses color tables for DWG/DXF files attached as references. If set to 1, the color tables for DWG/DXF references are handled as if they were DGN references, and therefore adhere to the specifics of Use Color Table.

Remap Colors on Copy

There is another reference preference that pertains to color, however this preference deals with how reference elements will be displayed when copied into the master model. Remap Colors on Copy, when toggled on, is used to remap an elements color attribute if an exact RGB match does not exist in the master models color table. For example, if the reference model contains a line with a color attribute of RGB (100, 100, 100) and that line is copied into a master model that does not contain that RGB value, Remap Colors on Copy will find the closest match as determined in the HSV space.

If this Remap Colors on Copy is toggled off, the color table number is held when the reference element is copied into the master model. For example, if a reference element is drawn using Color Number 3 and that element is copied into a master model with Remap Colors on Copy toggled off, Color Number 3 is held and the newly copied reference element will be displayed using Color Number 3 as defined by the master model's color table. The preference Use Color Table has no affect over this result.

Cache When Display Off and Reload When Changing Files preferences

The next two preferences have the same affect in MicroStation V8 as they had in previous versions of MicroStation. Given that, it is natural to ask why these preferences are being mentioned. Simply stated, Cache When Display Off and Reload When Changing Files have changed with respect to the amount of the reference model that is loaded into memory.

Previous versions of MicroStation used the preference Max. Element Cache to determine how much reference data was loaded into memory. This preference has been removed from MicroStation as the amount of reference data loaded into memory is no longer controlled at the application level, but passed to the operating system. While the underlying functionality of both Cache When Display Off and Reload When Changing Files has not changed, the underlying changes did warrant mention.

Store Full Path When Attached

For those readers who are familiar with versions of MicroStation previous to MicroStation V8, you might recall the preference Store Full Path When Attached. You may be curious why this has been removed. It is because there have been changes to how the Full Path of a reference attachment is used in MicroStation V8. The pre-V8 Full Path could only be written to a maximum of 65 characters, and this path was the first place that MicroStation searched when attempting to resolve the reference attachment. In addition, the Full Path was not written unless the user chose to do so during the time of attachment, or toggled on the reference preference Store Full Path When Attached.

Changes to MicroStation V8 have demoted the importance of the Full Path in the hierarchy of reference resolution. In addition, the Full Path (or Full File Specification in V8 terminology) is now written without input from the user. Both of these changes can be reversed through use of configuration variables, specifically MS_REF_FULLPATHFIRST and MS_DISALLOWFULLREFPATH. While the user can force MicroStation to first search the location defined by the Full File Specification when resolving the reference attachment, too much importance cannot be placed upon the assertion that relying upon the Full File Specification to resolve the reference attachment is limiting the flexibility of the reference system.

Default Nesting

Before moving to Default Nesting let's look at Allow Editing of Self-References. This is new to the MicroStation V8 list of reference preferences, however, its functionality is not new to MicroStation. In fact, Allow Editing of Self-References is a renaming of the pre-V8 preference Update Self Attachments, and as in previous versions of MicroStation, toggling on this preference will allow self attachments to be modified. It is important to note that this is the sole case in which reference elements can be modified, save for a copy into the active model.

Default Nesting is the preference that controls how attachments to a reference model are handled. There are three options for this preference: No Nesting, Live Nesting and Copy Attachments. No Nesting will ignore attachments to the reference model, and therefore will display only the graphics for the direct attachment. Live Nesting will allow for display of attachments to the reference model as well as continuously update changes to the nested attachment. Live Nesting maintains the hierarchical structure of the attachments to the reference model. Copy Attachments will make direct attachments of the attachments to the reference model. These attachments will function exactly like any other direct attachment.

It pays to note that both Live Nesting and Copy Attachments work in conjunction with the value set in the Nest Depth field. A value of two will allow for attachments to the reference model, as well as attachments to the attachment to be displayed, or directly attached. Lastly, Live Nesting is also controlled by the attachment setting Ignore Attachment When Live Nesting. More about this attachment setting can be found in the delivered Help file.

Copy Levels During Copy

The final reference preference to be addressed is Copy Levels During Copy. This preference comes into play when reference elements are either copied into the master model or the reference is merged into master. As with Default Nesting there are three states to this preference: If Not Found, If Overrides Exist, and Always.

The first state, If Not Found, will force the reference level to be copied into the master model if the master model does not already contain a level of the same name. The second state, If Overrides Exist, will copy the reference level on one of two conditions. The first condition is the same as If Not Found and the second condition is the same level exists in both the reference model and master model, but the reference model's level attributes contain overrides. The final state, Always, will unconditionally copy the reference level.

With respect to both If Overrides Exist and Always, when a level is copied into the master model and the level name already exists in the master model, the copied level name is prefixed with the reference name. Should that name not be unique to the master model's level table, the Logical Name will be included in the prefix. Lastly, elements from the reference's default level are always copied to the master model's default level. That is, a new level will not be created.

One thing to keep in mind is where these preferences are stored. Unlike the design file settings, the reference preferences are stored external to the design file. In fact, the preferences discussed in this article, along will all other preferences, are stored in the UPF (User Preference File). If you need to know which UPF you are using at any given time choose the Workspace Main Menu Bar item and the choose About Workspace.

A good working knowledge of the manifold reference preferences should allow for you to tailor both the appearance and functionality of the reference system to best meet your needs. Using this article, along with the delivered Help file, should provide you with the knowledge needed to customize your reference experience.

Comments or Corrections?

Bentley's Technical Support Group requests that you please confine any comments you have on this Wiki entry to this "Comments or Corrections?" section. THANK YOU!

The Reference Preference Redux [CS]