Where to set the _USTN_WORKSETDGNWSTEMPLATE variable so it's not overwritten by the msconfig file

If I set the _USTN_WORKSETDGNWSTEMPLATE variable in a workspace config file, the msconfig.cfg is being looked at again (Specifically on line 471) and overwriting what I set at the workspace level. In doing so there is no way I can see to point to an alternative DGNWS file name for different workspaces. 

Parents
  • No Marc. That info doesn't really pertain to what I was wanting to do. 

  • OK, thinking back I now recall trying DGNWS variables in a WorkSpace config and it not working. Locating them there was not critical to the examples that I was working on and I arrived at the WorkSpaceSetup.cfg as the best place to locate them without resorting to locking the variables (in my context at least). Typically:

    # locate DGNWS in WorkSet Standards folder
    _USTN_WORKSETSDGNWSROOT = $(_USTN_WORKSETROOT)Standards/
    _USTN_WORKSETDGNWS = $(_USTN_WORKSETSDGNWSROOT)$(_USTN_WORKSETNAME).DGNWS

    Using _USTN_WORKSETSDGNWSROOT gave the most reliable results. For more complex scenarios %if logic can be used in WorkSpaceSetup.cfg.

    Regards

    Marc

  • For my situation I wanted to be able to point to a different DGNWS template file that has a set of custom properties in it so I could use it to replace some older project DGNWS files that are missing those properties. Since those projects aren't using the index I didn't loose anything by deleting them and letting ORD regenerate from the template. 

    By setting it at the workspace level I can have different DGNWS files with different properties or index folders for different clients if I ever want to delete a DGNWS and let it regenerate. It will also now pick the DGNWS I want for that client without having to pick a project template, but that wasn't really my goal.  

    It seems odd that ORD first generates the variable in the msconfig file then will change it at the Organization, Workspace, or Workset level if set, but then looks back at lines later in the msconfig file and changes it right back to where it started . That makes setting it at any other level useless unless it's locked. I guess I don't get why the msconfig file is being looked at twice. Seems it should do what it needs to at the beginning then be done so it doesn't then overwrite changes made at other levels. 

  • That page is missing a few things, some of which affected Ryan and some that is missing, although maybe the article needs retitling a bit if all of it is included.

    The article is about where to keep your dgnws file, Ryan was asking about the variable about where the dgnws template comes from, that is missing on that page.

    Secondly the article doesn't mention that it's probably a good idea to %lock ALL those variables no matter where you set them.

    Most of our work is in ORD with US State DOT's. Many of them have their own workspaces that include a template DGNWS file. Most of them include their standards in an Organization-Civil folder and the variable to use that template are in their workspace.cfg file. We typically don't use the DOT workspace straight up, and the way we have it laid out they get included at the organization level (after our own organization standards are loaded).

    In my testing I've found setting the DGNWS template location at any level from workspacesetup.cfg to the workspace.cfg works fine but you MUST lock the variable. This is true for _USTN_WORKSETSDGNWSROOT as well.

    I've also found that for _USTN_WORKSETDGNWS to work it should really be set at the workset.cfg level and still must be locked.

     

  • the current msconfig drives me bonkers for overwriting or adding paths after they've been set (msdirs.cfg in the System folder also does a lot of this).

    Pretty much my rule of thumb is: if I set a _USTN variable, lock it. It fixes a lot of this.

     

Reply Children