No Workspace/No Workset uses last workspace name and won't allow browsing

When I attempt to use No Workspace (Client) -> No Workset  Browse uses the previous Workspace name to look for a folder No Workset\DGN.

This results in an error and does not allow browsing for files using No Workspace -> No Workset

Parents Reply
  • Unknown said:
    But can you tell me what controls the location of the No Workspace option

    ?

    Can I tell you?  I have no idea.  I still don't understand why something that suppose to do nothing requires a location and a workset, let alone how or what you are internally searching for to determine the proper location of nothing.

    I point workspaces to look on my server where I have my project workspaces and those workspace configs point to locations where I keep my project worksets.

Children
  • To overcome this issue. I have to create a No_workset.cfg and point the project variables to a fake location i.e. H:/, just so I can use the browse option.

    As DavidG mentioned.... WHY? Its function is not NOT link anything to a workset, so wjhy do we have to setup the links

    Ian
  • Take a look at (but DON'T change) msconfig.cfg, try a search in the text for "nowork" just to find the right area...

    Lines 301 to 306 define the place where NoWorkSpace/NoWorkSet.cfg lives.

    In my test setup with drives P (= project data: WorkSpaces/Worksets) and W (= resources: Organization) I can reproduce the information message (note this is not an error message, it speaks the truth, MicroStation is looking for a file and it is not there!) by deleting the copy of NoWorkSpace/NoWorkSet.cfg I put there as described in Solution 1 below.

    I offer two solutions:

    Solution 1

    The easiest: Copy NoWorkSpace/NoWorkSet.cfg to the place it's looking.

    Solution 2

    No one likes untidy folders so in C:\ProgramData\Bentley\CONNECT Edition\Configuration\WorkSpaceSetup.cfg which is where I assume redirection to your equivalents of P and W is being done add a variation of the if loop contained in msconfig.cfg, change the two instances of the variable _USTN_WORKSPACESROOT to _USTN_ORGANIZATION where indicated:

    In my case this is:

    # To hide the NoWorkSpace folder from the users

    %if !defined (_USTN_WORKSETCFG) && exists ($(_USTN_ORGANIZATION)NoWorkSpace/NoWorkSet.cfg)

     _USTN_WORKSETCFG = $(_USTN_ORGANIZATION)NoWorkSpace/NoWorkSet.cfg

     _USTN_HAVEWORKSET = 0

    %else

     _USTN_HAVEWORKSET = 1

    %endif

    Where I have already defined:

    _USTN_ORGANIZATION = W:\MstnCONNECT\Organization\

    Copy NoWorkSpace/NoWorkSet.cfg to the matching location

    This can be anywhere you like (on your LAN!) as long as the location and the if statement match. You could change the folder name but if it is out of sight why bother, that will only obscure its purpose.

    Marc

    Answer Verified By: DavidG 

  • Unknown said:
    but if it is out of sight why bother, that will only obscure its purpose.

    What is obscure it why the file needs to exist at all.  Is its sole purpose appears to be so we don't get an error message?  

    So far we've just gone in circles. It needs to exist because the program is looking for it.  Is that its whole reason for existence?  

  • MicroStation has always been designed to use project configurations. Open V8i without a PCF and you might well get errors depending on the configuration, generally in a text window.
    MicroStation CONNECT edition is designed to use WorkSpaces and Worksets in the same spirit as V8i. This message is an informative one to tell you that the configuration file that has been designed to handle a user's choice to select No WorkSpace/No Workset is not in the location that it is expecting to find it. There are two solutions available at present, as described above.
    The way this works may well be due for refinement, I have not checked for relevant SRs or Enhancement requests yet, just addressed the immediate question.
    Is choosing No WorkSpace/No Workset likely to be a common user choice or is it just that this came up during testing?
    If it is likely to be a common choice, why so?

    Marc

  • Unknown said:
    If it is likely to be a common choice, why so?

    Why not? Even if

    Unknown said:
    MicroStation has always been designed to use project configurations

    why shouldn't there be an invisible way to do without, to just fire up and get on - in a single user environment for example?