[ORD/CE] _USTN_WORKSETDGNWS

I am trying to understand this variable.

I would think it needs to be defined somewhere, but my attempts to define it don't seem to be working.

In this thread, Marc Thomas says he uses
_USTN_WORKSETDGNWS = $(_USTN_WORKSETSTANDARDS)$(_USTN_WORKSETNAME).DGNWS
%lock _USTN_WORKSETDGNWS

I'd like to do something similar except to save it directly next to the workset CFG more like
_USTN_WORKSETDGNWS         = $(_USTN_WORKSETSROOT)$(_USTN_WORKSETNAME).dgnws

But it doesn't matter what level I define that variable at, whether I lock it or not, it doesn't define correctly. The _USTNWORKSETNAME part always goes missing.

For example, I select a workspace, select a workset, open a drawing and exit ORD just to make sure that everything loaded all the way before I run my MSDBUG -5.
In the MSDEBUG.txt and the end where it shows the final complete definition of the variables, I can see

_USTN_WORKSETSROOT  = M:\Bentley\ORD\Configuration\WorkSets\
and
_USTN_WORKSETNAME  = INDOT_Test

I would think this should resolve _USTN_WORKSETDGNWS to  M:\Bentley\ORD\Configuration\WorkSets\INDOT_Test.dgnws
Which would be correct. Instead, I see

_USTN_WORKSETDGNWS  = M:\Bentley\ORD\Configuration\WorkSets\.dgnws 

It doesn't matter if I try to define this in WorkSpaceSettings.cfg or my Organization.cfg or even the workset.cfg.
And if I don't define it anywhere, that variable doesn't appear to get defined at all.

Any clue what I am doing wrong?

Parents
  • I'm finding it's important to remember what level a variable is at when it is defined*. _USTN_WORKSETNAME isn't actually available to be resolved until the WorkSet is actually chosen (by the user in the picker or from the file's branding) until the workset level of the configuration (this is true even if the value has been read from the user's UCF, technically the user level variables are defined after the workset level).

    Because of this, if you want $(_USTN_WORKSETNAME) to actually resolve you have to set the variable using it at the workset level.

    This is what I have in all my workset.cfg files to move our dgnws

    #-----------------------
    # DGNWS File
    #-----------------------
    # Do not change this on pain of death.
    # Must be set in the workset config.
    # Location must be at least read-only all project CADD users.
    _USTN_WORKSETDGNWS = $(_USTN_WORKSETSTANDARDS)dgnws/$(_USTN_WORKSETNAME).dgnws
    %lock _USTN_WORKSETDGNWS
    

    I've also run into an issue where if a DGNWS exists in the default location, ORD (and all Microstation based products) will use that one and ignore the _USTN_WORKSETDGNWS variable completely. I believe I last tested this in ORD 10.9, not sure it's been fixed since.

    Troubleshooting this while I was playing with it was a pain because if for some reason _USTN_WORKSETDGNWS wouldn't work ORD would create one in the default location and would use that until I deleted it even if I fixed the issue in the variable.

    * Normally this doesn't really matter. If you define one variable at the organization level:

    $org_var = $(workset_var)SubFolder/

    If $org_var isn't referenced until ORD is loaded then $(workset_var) is available and the variable resolution works. But if you try to use the value of $org_var before that, it'll fail. For example at the ord level doing:

    org_var = $(workset_var)SubFolder/
    %if exists($(org_var))
        result = success
    %else
        result = fail
    %endif
    

    Since workset_var hasn't been defined yet the %if will always fail, even if workset_var is set to a valid path, at the workset level. Apparently the use of the _USTN_WORKSETDGNWS variable requires all the components be available at the level it's defined at.

     

Reply
  • I'm finding it's important to remember what level a variable is at when it is defined*. _USTN_WORKSETNAME isn't actually available to be resolved until the WorkSet is actually chosen (by the user in the picker or from the file's branding) until the workset level of the configuration (this is true even if the value has been read from the user's UCF, technically the user level variables are defined after the workset level).

    Because of this, if you want $(_USTN_WORKSETNAME) to actually resolve you have to set the variable using it at the workset level.

    This is what I have in all my workset.cfg files to move our dgnws

    #-----------------------
    # DGNWS File
    #-----------------------
    # Do not change this on pain of death.
    # Must be set in the workset config.
    # Location must be at least read-only all project CADD users.
    _USTN_WORKSETDGNWS = $(_USTN_WORKSETSTANDARDS)dgnws/$(_USTN_WORKSETNAME).dgnws
    %lock _USTN_WORKSETDGNWS
    

    I've also run into an issue where if a DGNWS exists in the default location, ORD (and all Microstation based products) will use that one and ignore the _USTN_WORKSETDGNWS variable completely. I believe I last tested this in ORD 10.9, not sure it's been fixed since.

    Troubleshooting this while I was playing with it was a pain because if for some reason _USTN_WORKSETDGNWS wouldn't work ORD would create one in the default location and would use that until I deleted it even if I fixed the issue in the variable.

    * Normally this doesn't really matter. If you define one variable at the organization level:

    $org_var = $(workset_var)SubFolder/

    If $org_var isn't referenced until ORD is loaded then $(workset_var) is available and the variable resolution works. But if you try to use the value of $org_var before that, it'll fail. For example at the ord level doing:

    org_var = $(workset_var)SubFolder/
    %if exists($(org_var))
        result = success
    %else
        result = fail
    %endif
    

    Since workset_var hasn't been defined yet the %if will always fail, even if workset_var is set to a valid path, at the workset level. Apparently the use of the _USTN_WORKSETDGNWS variable requires all the components be available at the level it's defined at.

     

Children
No Data