MicroStation CE U14 and ORD 2020 R3 - More DGNWS file madness

This is a new problem but is also related to these two previous posts.

https://communities.bentley.com/products/administration/f/product-administration-forum/155429/sheet-index-seed/465187#465187

https://communities.bentley.com/products/administration/f/product-administration-forum/204959/ms-ce-u14---remapping-the-sheet-index

This post may be a bit complicated to follow, but I'm posting it here to reference when I create a service ticket with Bentley.

I'm working in both MicroStation CE U14 and ORD 2020 R3. 

I got around the Sheet Index problem by removing the .dgnws file altogether, then have the application automatically create a new one when the parent WorkSpace is selected in MicroStation or ORD. Setting the custom WorkSet properties in a template dgnws file referenced by the _USTN_WORKSETDGNWSTEMPLATE variable gives me those properties in the new .dgnws. The Sheet Index also works.

Here's the rub....
I am attempting to relocate the dgnws file to a different location.

I set the _USTN_WORKSETDGNWS variable to the full path for the file in the WorkSet cfg file. Upon loading and checking the variable I find the variable  _USTN_WORKSETDGNWS definition is pointing back to the default location and was updated at the User level. Nothing in my Personal.ucf sets this variable. Searching through the msdebug.txt file there is no setting of this variable other than my WorkSet definition. To get around this I locked the _USTN_WORKSETDGNWS in the WorkSet cfg file. 

Launching ORD the .dgnws file gets created in the correct custom location, custom properties are there, and I can edit the Sheet Index. However, editing any of the custom WorkSet properties results in them all getting removed when you exit ORD.

Launching MicroStation my custom _USTN_WORKSETDGNWS variable setting is ignored. The variable setting is correct, but the dgnws file gets created in the default location. On the plus side I can edit both the Sheet Index and the custom WorkSet properties.

So after all that I think the .dgnws file is going to remain in its default location with the WorkSet cfg file.

One other note about the Sheet Index....
If I create a new WorkSet using a template that has predefined folders in the Sheet Index the folders are retained in the new WorkSet. Removing the .dgnws file and having the the application create a new one on the fly from the _USTN_WORKSETDGNWSTEMPLATE the folders are not present.

Parents
  • In setting up our ProjectWise Managed Workspace I only got this scenario to work by setting:

    1. _USTN_WORKSETDGNWSTEMPLATE in our Corporate standards. Full path and filename.
    2. _USTN_WORKSETSDGNWSROOT in the Workspace config file plus I lock it %lock _USTN_WORKSETSDGNWSROOT
    3. _USTN_WORKSETDGNWS in the Workset config file, full path and filename

    I think the template variable could go at any level. I also found that if I use the template file that ships with ORD, we couldn't edit it with either ORD or MicroStation. If I used the template file from MicroStation Update 14, it worked.

    Putting _USTN_WORKSETDGNWS anywhere but the workspace config made a huge number of weird things happen. Sometimes it would create the dgnws in the wrong location, sometimes it would create a dgnws for every workset in the correct location. I'm not sure the lock is necessary but I think I ran into the same thing you're seeing where it would get changed later on.

    Similarily putting _USTN_WORKSETDGNWS in the Workspace also caused weird things to happen. I'm not sure full path and filename is nessary if the worksetdgnws root is set properly, but it's working and I'm not risking breaking it.

    We also found, and this may be a managed workspace specific setting, that having a dgnws with the proper name in one of the other locations that MicroStation/ORD look for it in, causes them to lock onto that file and use it and not create one in the correct location. Very frustrating!

     

Reply
  • In setting up our ProjectWise Managed Workspace I only got this scenario to work by setting:

    1. _USTN_WORKSETDGNWSTEMPLATE in our Corporate standards. Full path and filename.
    2. _USTN_WORKSETSDGNWSROOT in the Workspace config file plus I lock it %lock _USTN_WORKSETSDGNWSROOT
    3. _USTN_WORKSETDGNWS in the Workset config file, full path and filename

    I think the template variable could go at any level. I also found that if I use the template file that ships with ORD, we couldn't edit it with either ORD or MicroStation. If I used the template file from MicroStation Update 14, it worked.

    Putting _USTN_WORKSETDGNWS anywhere but the workspace config made a huge number of weird things happen. Sometimes it would create the dgnws in the wrong location, sometimes it would create a dgnws for every workset in the correct location. I'm not sure the lock is necessary but I think I ran into the same thing you're seeing where it would get changed later on.

    Similarily putting _USTN_WORKSETDGNWS in the Workspace also caused weird things to happen. I'm not sure full path and filename is nessary if the worksetdgnws root is set properly, but it's working and I'm not risking breaking it.

    We also found, and this may be a managed workspace specific setting, that having a dgnws with the proper name in one of the other locations that MicroStation/ORD look for it in, causes them to lock onto that file and use it and not create one in the correct location. Very frustrating!

     

Children
No Data