Where and how is the variable _USTN_WORKSETDGNWS defined?

RE: Where and how is the variable _USTN_WORKSETDGNWS defined?

Charles Meuser — Thu, 09 Dec 2021 13:13:23 GMT

Thanks Marc!

RE: Where and how is the variable _USTN_WORKSETDGNWS defined?

Marc Thomas — Thu, 09 Dec 2021 12:05:33 GMT

Hi Charles, I've filed an SR about this one on your behalf.

For anyone concerned about this problem, the active defect is no 658928 "WorkSet custom properties vanish when DGNWS and CFG are in different locations". Please file an SR referencing this defect number and discussion.

I have updated it with further details to assist the developers.

RE: Where and how is the variable _USTN_WORKSETDGNWS defined?

Charles Meuser — Wed, 08 Dec 2021 14:43:49 GMT

Marc,

Is there a timeframe or specific build that we can expect this issue to get resolved? Or has it already been resolved?

Thanks,

Chuck

RE: Where and how is the variable _USTN_WORKSETDGNWS defined?

Marc Thomas — Mon, 26 Jul 2021 16:43:13 GMT

Yes completely.

RE: Where and how is the variable _USTN_WORKSETDGNWS defined?

Charles Meuser — Mon, 26 Jul 2021 16:35:32 GMT

Thanks Marc.

So do you see our frustration? Don't get me wrong, I love the new functionality and all, but it gets old when, someone who is the admin and wants to add these features when a) it works in one release, but not in another, b) only works in the "Bentley" controlled environment, c) all the above.

RE: Where and how is the variable _USTN_WORKSETDGNWS defined?

Marc Thomas — Mon, 26 Jul 2021 16:27:43 GMT

I just tested adding a custom field in one of my configs where the DGNWS is with the project data, the field was not displayed in a new session. I will flag this with the team.

RE: Where and how is the variable _USTN_WORKSETDGNWS defined?

Charles Meuser — Mon, 26 Jul 2021 11:07:25 GMT

Tim,

You nailed it. The fields are available ONLY if the DGNWS file is in the same folder as the workset cfg file ( _USTN_WORKSETSROOT). The fields ARE NOT available if the DGNWS file exists anywhere else even the defined DGNWS root folder (_USTN_WORKSETSDGNWSROOT)

RE: Where and how is the variable _USTN_WORKSETDGNWS defined?

Charles Meuser — Mon, 26 Jul 2021 11:02:06 GMT

Marc,

I'm using release 16. I know I created the fields earlier this year probably with Release 15. I filed the SR in April and notified of the defect.

RE: Where and how is the variable _USTN_WORKSETDGNWS defined?

Tim Hickman — Fri, 23 Jul 2021 14:36:29 GMT

I think the DGNWS file gets the needed properties, but if it is located other than with the workset it doesn't get read. He stated that if he moved the created DGNWS file under the worksets folder then he was able to see the added properties.

BUT... if I copy the DGNWS file to the Workset folder, all the fields are present and works "as it should"

or am I reading it wrong ?

RE: Where and how is the variable _USTN_WORKSETDGNWS defined?

Marc Thomas — Fri, 23 Jul 2021 13:38:50 GMT

Hi Charles,

A defect titled "WorkSet Template Custom Properties not copied to new WorkSet" was fixed in MicroStation Update 14 (10.14.00.109). The description of this matches your experiences.

Which application versions are you using?

RE: Where and how is the variable _USTN_WORKSETDGNWS defined?

Tim Hickman — Thu, 22 Jul 2021 15:37:21 GMT

here is another DGNWS woe:

https://communities.bentley.com/products/road___site_design/f/geopak-inroads-mx-openroads-forum/217047/managing-sheet-index-dgnws-for-different-companies-disciplines-on-the-same-project

RE: Where and how is the variable _USTN_WORKSETDGNWS defined?

Tim Hickman — Thu, 22 Jul 2021 15:05:25 GMT

yepp - this was one of my arguments when this was first introduced.

RE: Where and how is the variable _USTN_WORKSETDGNWS defined?

Charles Meuser — Thu, 22 Jul 2021 15:02:32 GMT

Tim, yeah, it works. BUT our worksetsroot folder is located within the WorkSpaces folder (<WorkSpace_Name>/Worksets) and since its on another drive and write locked, users can't write to it and taking away all the cool functionality of the DGNWS.

RE: Where and how is the variable _USTN_WORKSETDGNWS defined?

MaryB — Thu, 22 Jul 2021 15:01:13 GMT

*sigh*
Perhaps Bentley should have asked the user base how we normally store project information vs. workspaces?

RE: Where and how is the variable _USTN_WORKSETDGNWS defined?

Tim Hickman — Thu, 22 Jul 2021 14:52:09 GMT

so you move the DGNWS file from the workset standards folder, to the actual workset root folder and then it works ?

I am having similar issues when trying to separate my engineering/working data from the configuration.

The other frustrating part on my end is the generic exception logs that get generated - not much help for me.

I can get the Bentley products to read the new locations and have no issues. My problem comes with the creation process for anything new. For some reason the creation process (for me) doesn't like the data being located outside of the Bentley directory structure.

but the both of us - as well as others - are not configuring things the exact same way - so it seems that Bentley has issues with us changing these.

RE: Where and how is the variable _USTN_WORKSETDGNWS defined?

Charles Meuser — Thu, 22 Jul 2021 13:20:36 GMT

Thanks for that explanation Marc.

A follow-up to this, our organization has several different disciplines and utilizes both Bentley and Autodesk apps. We have adopted a standard project folder structure and is standard across all these disciplines. Project folders are created to the production drive by our IT dept. using a script that automates the process (copying folders from a master and assigning permissions).

The Configuration folder is located on a "workspace drive". The workspace drive supports all our CAD products. We currently have basically 2 main WorkSpaces types, Corporate, Public client (ie PennDOT, WVDOH). The project folders are the same for both. Once the folder is created, if the project is using Bentley CAD apps, I create the projects workset files by just copying a master and editing a variable or two in the applicable WorkSpaces/Worksets folder. This process has always worked for in the past.

So following your recommendation, I edited my WorkSpaceSetup config file to the following

_USTN_WORKSETROOT = $(Client_Project)$(_USTN_WORKSETNAME)/
_USTN_WORKSETDGNS = $(_USTN_WORKSETROOT)02 Draw/
_USTN_WORKSETSTANDARDSDIRNAME = 02 Standards
%lock _USTN_WORKSETSTANDARDSDIRNAME
_USTN_WORKSETSTANDARDS = $(_USTN_WORKSETROOT)02 Draw/05 Application/$(_USTN_WORKSETSTANDARDSDIRNAME)/
%lock _USTN_WORKSETSTANDARDS
_USTN_WORKSETSDGNWSROOT = $(_USTN_WORKSETSTANDARDS)
_USTN_WORKSETDGNWS = $(_USTN_WORKSETSDGNWSROOT)$(_USTN_WORKSETNAME).DGNWS
%lock _USTN_WORKSETDGNWS

In my configuration testing sandbox, I created a NEW project workset in my corporate WorkSpaces/Worksets/ folder following my existing workflow.

Using MicroStation Connect, I selected the corporate WorkSpace and the NEW Workset..BANG, a NEW DGNWS file got create to the _USTN_WORKSETSDGNWSROOT location from the standard DGNWS template file that had all of my custom fields. Perfect! I closed MicroStation.

SO NOW THIS IS THE FRUSTRATING PART!

I re-launched MicroStation Connect, selected the same WorkSpace and Workset. The custom fields are no longer shown. I confirmed the DGNWS file IS in the desired location.

I created a new file to the "New" project. I the created another file in the same project and folder. I closed MicroStation.

I relaunched MicroStation, the Corp WorkSpace and NEW Workset stuck and the two NEW files I created were listed as associated with the Workset.

I added a couple of custom fields, opened a file then exited MicroStation, I relaunched MicroStation and the custom fields are gone.

So, it "Appears" that I was able to redirect the DGNWS file to another location, BUT it also appears that MicroStation really doesn't recognize it after the original creation of it. I've deleted and re-created the DGNWS several times with the same results.

BUT... if I copy the DGNWS file to the Workset folder, all the fields are present and works "as it should".

RE: Where and how is the variable _USTN_WORKSETDGNWS defined?

Marc Thomas — Fri, 25 Jun 2021 15:29:00 GMT

I've been working on some non-ProjectWise configurations for users over the last few weeks and offer the following suggestions relating to the DGNWS.

Where a configuration and project folder structure is consistent I'm recommending that key folder redirections are made in the WorkSpaceSetup.cfg in the custom configuration.
For clarity of purpose we use the name 'Standards' for the root folders containing DGNLIB and other resource folders.
For WorkSets this name is set by _USTN_WORKSETSTANDARDSDIRNAME. That's easy to spot, however I've noticed that MicroStation hardcodes the 'Standards' folder name in msconfig.cfg (which I will follow up on).
This is easily fixed by first defining _USTN_WORKSETSTANDARDSDIRNAME with a user's folder name, then defining:
_USTN_WORKSETSTANDARDS = $(_USTN_WORKSETROOT)$(_USTN_WORKSETSTANDARDSDIRNAME)\ to include the redefined folder name.
having done that the DGNWS can then be located in the WorkSet 'Standarsd' folder by defining:
_USTN_WORKSETDGNWS = $(_USTN_WORKSETSTANDARDS)$(_USTN_WORKSETNAME).DGNWS
_USTN_WORKSETSDGNWSROOT does not need to be defined for this to work so appears redundant. However it could be used if the DGNWS was required to be in a sub-folder of _USTN_WORKSETSTANDARDS, e.g.:
_USTN_WORKSETSDGNWSROOT = $(_USTN_WORKSETSTANDARDS)/<path>/
_USTN_WORKSETDGNWS = $(_USTN_WORKSETSDGNWSROOT)$(_USTN_WORKSETNAME).DGNWS

The complete block I've put in WorkSpaceSettings.cfg is:

MY_PROJECT_SERVER = <path>/
_USTN_WORKSETROOT = $(MY_PROJECT_SERVER)$(_USTN_WORKSETNAME)/
_USTN_WORKSETSTANDARDSDIRNAME = <MyStandardsFolder>
%lock _USTN_WORKSETSTANDARDSDIRNAME
_USTN_WORKSETSTANDARDS = $(_USTN_WORKSETROOT)$(_USTN_WORKSETSTANDARDSDIRNAME)\
%lock _USTN_WORKSETSTANDARDS
_USTN_WORKSETDGNWS = $(_USTN_WORKSETSTANDARDS)$(_USTN_WORKSETNAME).DGNWS
%lock _USTN_WORKSETDGNWS

The variables are locked to ensure that other CFG files do not change them. OpenBuildings Designer for instance, to ensure that the delivered example WorkSets operate as designed, sets _USTN_WORKSETSTANDARDSDIRNAME = Standards.

In multiple WorkSpace scenarios where perhaps the root folder for the WorkSets vary, some or all of these could be put in the WorkSpace CFG.

The other interesting thing which may help, obvious in hindsight, is OOTB the configuration results in the folder structure: ....\<WorkSpaceName>\<WorkSetName>\ so WorkSets are always contained within a WorkSpace folder.

By redirecting _USTN_WORKSETROOT to a path that does not include _USTN_WORKSPACENAME as shown above, the WorkSets can be stored in any required location, while the benefits (if needed) of assigning differing resources by WorkSpace within the configuration are retained, and the grouping of projects in the UI is retained.

I'll post some examples over the next month, probably in my blog.

Hope this helps.

RE: Where and how is the variable _USTN_WORKSETDGNWS defined?

Charles Meuser — Thu, 24 Jun 2021 12:29:12 GMT

Those are very good points and I agree with all of them. Working outside PW, the DGNWS file and the functionality that can be associated with it would helpful, especially when using fields in title blocks and all that.

In the past, I configured our workspaces to a central location distant from the actual project CAD files. This was done to have all our users resource standards from once central location (DUH!), prevent them from editing said standards and allow our IT folks to easily assign the necessary file access permissions. Its been a disappointment that even at Release 16, the DGNWS file still can't reside "outside the standard "Configuration" folders. At to your point, _USTN_WORKSETSDGNWSROOT is a variable that serves no purpose.

I filed an SR several months ago and it is indeed a defect (as they call it) Defect 1116741and its anticipated to be addressed in Release 17. 16 Releases too late.

RE: Where and how is the variable _USTN_WORKSETDGNWS defined?

caddcop — Thu, 20 May 2021 12:34:56 GMT

Well, this is sort of embarrassing! But it's not 100% my fault!

First and foremost, it turns out that my inability to get the DGNWS file to work was due to a permissions setting in my target folder location. Once I realized that, I was finally able to get the DGNWS file to get created once a file was opened in the Workset. However, do you think an error message, like "Unable to create DGNWS file. You do not have sufficient permissions to complete that task." might have helped.

With that out of the way, allow me to rant a little:

There are a lot of variables in CONNECT that are potentially stupid! I know that sounds harsh, but hear me out.

There is a variable named _USTN_WORKSETDGNS which is defined as the "Search Path for design files". I don't know how others work, but in a large organization like a DOT, or on large projects, DGN files are spread all over the place in a project folder structure. Usually, by discipline but even within one discipline, many departments keep sheet files separated from drawing or model files. If there is a purpose for this "search path" that would justify defining it to all the possible DGN file locations, it would be nice to know what this actually does.

Another variable is _USTN_WORKSETSTANDARDSDIRNAME which is defined as the "Base directory name for Standards of WorkSet. At the time of creating new WorkSet, this name is appended to the WorkSet root directory path". By default, it is defined as "Standards". Additionally, there is a variable _USTN_WORKSETSTANDARDS which appears to be the combination of the previous variable and the WorkSet root directory path, as the previous variable's definition explain. Well, on our project folder setup, I needed to redefine the _USTN_WORKSETSTANDARDSDIRNAME to match our folder names. After making that changes, I thought that _USTN_WORKSETSTANDARDS would naturally adjust to match this new definition. But no, it had no effect. I had to redefine _USTN_WORKSETSTANDARDS to use the WorkSet root directory path plus my definition of _USTN_WORKSETSTANDARDSDIRNAME to get it to work.

One last observation - this is a ProjectWise observation, but it might apply to a non-PW workspace: When you review a path variable in the configuration dialog box, if the Value displays back-slashes as the path separators, that is an indication that the path defined actually exists. If you see the Value is still using forward-slashes, it means that the folder specified is non-existent. For example, the previously mentioned _USTN_WORKSETDGNS variable displays using forward slashes since my DGN folder names is seldom DGN nor is it located right below the top level folder of the WorkSet.

I still have no idea how or where the default location for the DGNWS is defined, but in ProjectWise, I finally undefined it in my Predefined CSB's to get the full path definition to stick. However, even though its definition claims it to be a full path variable, it may work when defined as a name only value if the variable _USTN_WORKSETSDGNWSROOT is correctly defined to its folder path.

RE: Where and how is the variable _USTN_WORKSETDGNWS defined?

MaryB — Fri, 14 May 2021 15:53:51 GMT

Good to know - thank you!

RE: Where and how is the variable _USTN_WORKSETDGNWS defined?

Rod Wing — Fri, 14 May 2021 14:37:18 GMT

Yes, that works.

RE: Where and how is the variable _USTN_WORKSETDGNWS defined?

MaryB — Fri, 14 May 2021 14:22:50 GMT

They really should get that fixed...

Can you "predefine" _USTN_WORKSETDGNWS in the workset cfg so that when you move the DGNWS, it will be automatically located?

RE: Where and how is the variable _USTN_WORKSETDGNWS defined?

Rod Wing — Fri, 14 May 2021 13:38:36 GMT

This is a problem outside of ProjectWise too. I can't seem to find it now, but there was a Ticket/Defect filed about this a few years ago. You cannot change the DGNWS variables to have the dgnws files automatically created in a folder other than the default location. Once created you can copy the dgnws file to another folder and define the _USTN_WORKSETDGNWS variable to pick it up in the new location.