I am attempting to create custom configuration variables in order for the workset configuration file to find a directory path defined by the variables (similar to defining MS_DEF to point to a particular directory for finding dgn files). In particular, I am attempting to have two custom variables (MS_POINTCLOUDDIR and MS_REALITYMESHDIR) located within the workset.cfg file point to directories when one executes Point Cloud> Attach and Reality Mesh> Attach. Any idea how I may get this concept to work? Am I merely missing configuration variables which already exist (as they exist for attaching dgns, refs, and images)?
Thanks!
Mark
Mark Plum said:MS_DEF
MicroStation configuration variables have the prefix MS_. That enables you to distinguish them from your custom configuration variables.
MS_
Mark Plum said:I am attempting to have two custom variables (MS_POINTCLOUDDIR and MS_REALITYMESHDIR)
You've created a maintenance problem. How will you distinguish your variables from MicroStation's variables in, say, a year's time? Choose a distinct prefix that means something to your project or organisation. For example, since your organisation is Poe and P Associates, why not PP_POINTCLOUDDIR and PP_REALITYMESHDIR.
PP_POINTCLOUDDIR
PP_REALITYMESHDIR
Regards, Jon Summers LA Solutions
OK, no problem with the change of syntax of course (and I understand your point). Still, let me change those variables to PP_POINTCLOUDDIR and PP_REALITYMESHDIR and point those to a particular directory. How do I get Point Cloud> Attach and Reality Mesh> Attach to default to that (those) directory(s) at the workset level? Also, what happened to runmacro.ma (it does not seem to be included with Connect (or has not been updated to this latest edition of MicroStation)?
Tim, the whole purpose of defining these variable is to insure that all of the needed references are in one location (at least that is how we are structured here). Nonetheless, yes, of course THAT file will will be in a non-specific location (and glad that it does not lose intelligence as such). When executing the attach reference function, however, the attach reference dialog goes right back to the location as defined in the MS_ reference variables as per the workset.
agreed. I am saying that is the exception. None of the other dialogs work that way. That variable was added for that specific issue.
Cells, color tables, linestyles, etc... do not work that way. It remembers the last place used.
Timothy Hickman
CADD Manager | CADD Department
timothy.hickman@colliersengineering.com
Main: 877 627 3772|
1000 Waterview Drive Suite 201 | Hamilton, New Jersey 08691
Tim, Isn't the question where does the file>open or File>attach dialogs start? yes they default to the last used location but in the case where they have not been used then what variable controls where they start. MS_def does this for design files.
Point Clouds and Reality mesh attach dialog both seem to use _DGNdir as the base directory to start. Since this is just the active files directory it doesn't seem to be able to be controlled like the OP desires.
~HTH
John.
yep
I think there is a misconception as to what these variables control or how they function. Yes a default is provided, but most assume that this is what holds and it as to how it will always open to. I believe there are several situations here, each to do with these various dialogs.
I don't think it is a question of where it starts, but more along the lines of where it can be pointed permanently. In other words, they don't care where they browsed last, they want it to always open at one location, no matter what.
and this is not how it currently functions.
Tim, PRECISELY! Practically every single user (ADMIN) I have spoken with through many different companies would like to have a structure by which the current options are available to the end users and also "fixed" directories where information may always be found. Bentley has attempted to fix this situation through a "Standards directory" (V8i) and now an "Organization" directory (CONNECT), it seems, but such does not exactly "remedy" this long standing situation.
And yes, John, you understand the situation well.
the intent of those directories was not an attempt to fix this issue.
Tim: Yeah, no doubt. Nonetheless, the issue still exists... I actually like the new structure within CONNECT although it has taken a bit willpower to embrace it.