Howdy Mr. B!

Project-specific Project Defaults is a blessing and curse sometimes, even for me. Mostly because I work on so many different projects for so many different people and those projects are separated into 100's and 100's of different locations; enough about my problems.  ; )

From your question you obviously know what Project Defaults are all about so I don't have to get into that, so here is my fairly direct answer.

It depends.

Sorry.

But it does depend on how you have your folders structured and your files placed, but here is a technique that will alleviate some of the browsing pain.

The Project Default does two things. The top part opens specific files, while the lower part points to folder locations.

The lower part is usually filled in with a path to the folder that contains that type of data, like E:\Zen\Dude\Work\InRoadsStuff. This is what most users do. Actually, most users probably don't even use Project Defaults. But I digress.

Specific paths are really needed when your InRoads data is separated. The DTMs are in this folder, the ALGs are in that folder, the FWDs are over there, and so on. But instead of entering a specific path you can specify a 'Variable'. Basically a variable is something that stands for something else; a substitute or alternate way of calling something out. There are MicroStation variables and even Windows variables. And InRoads can use both in the Project Defaults. You can tell a variable string because it usually has a $ in front of it (someone should explain the history of that $ origin to me someday. I suppose it might have something to do with someone getting rich off of it. Hello World).

The thing about MicroStation and Windows variables is that they have to be created and stored somewhere before they can be used. And who wants to do that? Maybe your CAD Manager? But there is a variable 'hack' that I like.

$(_DGNDIR)

Throw this baby in those lower fields and those paths will default to the directory where the DGN file that you opened exists. And that's not a bad place to be, especially if you have your InRoads folders under the main DGN folder. Or maybe the job is small enough where you store your InRoads data in the same folder as the DGN that you are working with. If that's the case, you are golden!!

To enhance this Default Directory Path location you can add subfolder locations onto this variable like this:

$(_DGNDIR)\InRoadsFiles

It just has to be under the DGN directory where the MicroStation DGN file is that you are opening. It can't browse sideways, or up and then down, or onto another planet.

Now, about the top part of this dialog box, the location of the intricately indispensable XIN . . . that can be located with this DGN variable, but only if its name is always the same. Because it has to be written into the variable string like:

 $(_DGNDIR)\TheZenDude.XIN

This is awesome if you work for an agency that calls their XIN by name, like ODOT.XIN, SRP_Survey.XIN or PoLB.XIN. Plug that name after that variable, and any path that it needs (if it's under the DGN folder) and 'bang' . . . Bob's your uncle!!** That XIN will load from the DGN folder every time without a second thought from the user.

Now, if you set up the Project Default this way, and that XIN isn't found by that variable, then you'll get a message like this:

This is just your stereo-typical alert that says, "Hey user-person, the XIN that you expected to be there . . .  isn't. So, I'm just going to use the out-of-the-box XIN, and by the way, you don't have Write permissions to it. Sorry dude."

Whatever . . .

Then you know that you need to open up your project XIN.

Well, I hope that helped at least a little. I've personally been using this set up off and on lately and am pretty happy with it.

Try it! You might like it!!

 Civilly yours,