Upgrading Models and update to Revit Make Local

It is that time of the year when users start transitioning projects to the newer version of Revit. The first service pack was released this week and most now feel comfortable making the transition.

I am always amazed at how many out there still use the Revit Make Local utility I created years ago, which was last updated in April 2010. I’ve received numerous comments and emails over the last years requesting an update. I have even had a few come to me last week at RTC in Vancouver to thank me and asked nicely when I was going to update it to work with Revit 2014! So I finally cracked down under the pressure and spent some time brushing up on AutoHotkey again (I need to build some scripts at work anyway) and made the necessary changes. You can download the latest Revit Make Local V5.1 and try it out. Please note that I have only tested in 2013 and 2014 OneBox, but it should work on stand-alone and past versions as well. It is becoming a royal nightmare to support all versions of Revit because there are so many variations between them (varying journal file and executable paths, different journal contents, the arrival of OneBox, and now also the obsolete Programs folder in 2014!). So this might truly be the last update, but if it does require more work in the future and I decide to indulge, I will drop parts of the script that support older versions to simplify things.

This brings me to the real intent of this post. Why do users still like this utility instead of the built-in local file functionality? Because besides the fact that local files do not go into their dedicated folders, there is absolutely no safeguard from accidental upgrading. It is astonishing to me that we still don’t have anything built-in to address this issue. The current upgrade dialog is only displayed after upgrading starts and does not present us with the opportunity to cancel, not even the “X” button at the top-right corner.

There are possible hacks to find which Revit version and flavor was last used to save the file (this avoids the use of a naming convention as required for the Revit Make Local utility), but there is nothing visible to the user in the operating system that displays the file version. You have to open the file in Revit to find out.

Revit is typically very verbose. It issues plenty of warnings and dialog boxes to keep users informed and usually even demands their input. However when it matters most, it doesn’t even pause and ask for user feedback. We really need to be consulted when an older file is about to be upgraded so we can take a decision and not just inform us after the fact!

The upgrade process is a massive painful exercise when you have a ton of linked files, especially if you forget to close the appropriate linked file worksets (I just close all of them when upgrading). I think we need a dialog like this that provides the following options:

Note: The above mock-up was created with Pencil.

What do you think? If you agree, I encourage you to send feedback to Autodesk directly and reference this post.

Upgrading Models and update to Revit Make Local

Streamlining Local File Creation – GUI (v5)

With the launch of Revit 2011, I finally completed the application I started and stopped back in January 2009 when Revit 2010 was still in Beta. I wasn’t sure this approach still had value due to Revit’s new native ability to create local files directly from the Open dialog. Having had a very busy couple of months following the release of Revit 2010 and after some changes in my workplace, this fell on the sidelines. Believing that this was still the most efficient way to work in workshared projects, it was time to Git-R-Done!

The application was mostly re-written to incorporate a GUI option. I have always favored the shortcut approach because it is a much faster way of working with local files as compared to navigating to your project folder every day. Adding a sidebar link to the Open dialog works quite fast in addition to Revit’s functionality of automatically creating a local file, however depending on the method used to add such link, naming it is a whole other issue! Not to mention the inability to organize locals into different project folders and doing other types of checks in the process.

The drawback of the previous app. was decentralization and the fact that you had to manually create a shortcut, remember how to do “switches” for different options, etc. So the new version takes all that out of the equation. The new version is meant to be located in one place: on the network or your local drive with a shortcut to the executable on your PC. You simply navigate to find your Central File folder and then right-click on a Central file to pick one of three options (or double-click to launch the default). Most settings have been pulled out of the script and into settings.ini, such as default options, links and paths. The app. automatically creates the desktop shortcut for the project and option chosen (you can uncheck the option to create the shortcut if desired). Next time you will be able to launch this shortcut to perform the same actions without the GUI.

The launcher has been tested on Vista Enterprise (x64) and Windows 7 (x64), but should also function properly on XP. It works with Revit 2009, 2010 and 2011. If you’re still on 2008 you’re nuts, but you should be able to use this app. anyway!

The other notable enhancement is Build Checking. Now only the machines with builds older than the project’s build will be warned and once they are upgraded, the message goes away automatically. This data is written in projects.ini which is created either in each central file folder or a centralized location of your choice. Here’s an example warning (not the final 2011 builds):

 

So just click on the image below to download it from the AUGI forum post (free membership required). Feel free to add comments to this post or to the Documentation page and hope you find it useful!

Special thanks go to David Kingham and James Vandezande for openly sharing their AHK scripts, solutions and ideas!

Streamlining Local File Creation – GUI (v5)

Streamlining Local File Creation – update (x64) v4

Hi all, please accept my apologies for not posting much lately. I’m currently on an “expedition” in Eastern Europe and spend most of my free time blogging about that instead of Revit! I’m sure you’re smart enough to find it if you want to know more ;) I’ll hopefully be able to return to the usual weekly schedule in July/August.

Anyway, I’ve completed the update of the Local File Creation script a month ago and forgot to post about it here. So this will be an easy post for me! With the new functionality built into Revit 2010, there’s less need for such a script. However we still intend to keep on using it as we have other functionality built-in which doesn’t exist in the Autodesk solution. So this is tailored specifically to our needs.

In the future I will be making changes to this script to include a GUI option and have the application make desktop shortcuts automatically. The application will also be centralized (either on a network or local drive…your choice). This means that you won’t need to keep placing a copy of the exe file in each project folder like you do now. This will make updating the app much easier. But that will be released later and most of the functionality will be very similar to the current version. These are the main updates:

1. Compatible with 2010 (32 & 64 bit) and works all the way to 2009 (32 & 64 bit) and 2008.
2. Adjusted some of the logic so now when creating a Detached copy, the Central is not copied to the C drive. You can also create a detached copy of a project while a local file for the same project is still running. This wasn't possible before.
3. The script ends properly and the splashscreen should not persist after it finishes. Please see the Known Issues section in the Readme.txt file for one case where you might still notice this problem.

Note that for both 32 and 64 bit versions, the installation folder is assumed to be C:\Program Files\ and that you’ll have a 32 bit version of Revit on a 32 bit OS and vice versa for 64 bit. As always, you can download the zip containing the documentation, AHK script, the compiled executable and icon from this AUGI thread (first post with version history). Enjoy!

Streamlining Local File Creation – update (x64) v4

Streamlining Local File Creation – update (x64)

The script has been updated to work with the following combinations:

1. 32 bit Revit on a 32 bit OS
2. 64 bit Revit on a 64 bit OS

It will look for an installation in the folder Program Files, so if you changed the install location, it won’t work. The previous script was a bit more flexible and automatically retrieved the custom folder that you might have used as your program installation folder. However on a 64 bit OS, the parameter is retrieving the Program Files (x86) folder, which is not the correct location for the 64 bit install. Because of this, I just hard-coded the folder into the script in lieu of the parameter.

You can download the zip containing the documentation, AHK script, the compiled executable and icon from this AUGI thread (first post with version history). Enjoy!

Streamlining Local File Creation – update (x64)

Streamlining Local File Creation - update

Earlier this month, I posted about a script/program to streamline local file creation. I finished some new updates which you can find on the AUGI thread Transparent Local File Creation (see the first post). I'm calling it Version 3, whatever that means :) I have added a readme file to the zip file that contains all the details you need to know about how it works, version history, etc. Here are the new additional features:

a) Check for Revit build between users working on the same project. The program will warn the users using a build other than what was used originally to create the first local file (using the script/program). This will help in alerting the BIM Manager/Workstation Administrator that some team members need to be upgraded.

b) Check if Revit is already open with a local version of the same project, belonging to the user that is running the script. If such case is detected, a warning will be issued and execution will stop.

c) The program will launch any Revit version from 2008 onwards (until they change the naming again!). So you'll be able to use it in a couple of weeks when the 2009 line-up is released!

d) Added an informative, animated splashcreen for a few seconds while a Revit session is launched.

e) Revit will now always open maximized.

If you find any problems, feel free to contact me. I'm also eager to hear your suggestions to make this a more useable tool. At the moment I have stayed away from using a GUI interface to select the project to launch, as this is tailored to our firm procedures, naming conventions, etc., and so far, it has been working very well for us.

Streamlining Local File Creation - update

Streamlining Local File creation

Creating local files for workset-enabled projects can be confusing to users and is quite an unelegant task. A while back I started a thread on the AUGI Revit forums titled "Transparent Local file creation". Thanks to AutoHotKey, I was able to come up with a nice, automated way to help teams working on workshared projects get started every morning in a consistent and easy way.

Since then the thread has had over 2,400 hits and numerous users have contributed to the ideas and solutions of this script. Today I finished version 2 and decided to post about it here. If you like what you see, go to the thread above (or click here) and download the script. I hope it will be as useful to you as it has been to me and a lot of AUGI members. All you need to do is to place a copy of the exe file (compiled version of the AHK script) in the central file folder and have team members create shortcuts to this file on their local drives (the Desktop is ideal). Then just double click the shortcut and wait until it's finished doing it's magic!

-------------------------------------------------------------------------------------------------

The script will do the following:

1) Check if the Central file exists. Filename is assumed to be XXXXX #VV central.rvt, where XXXXX can be anything of any length, # is the discipline (A, S or MEP, where the 3 letters in MEP can be expressed in any order) and VV is the version number (since we’re on 2008, we would use 08, but the script doesn’t care about this and you could in theory type anything). The spaces shown in the filename can be any character you want, including a space. So 123456789 Project_A08-Central.rvt would work the same as 123456789-Project-A08_Central.rvt (you get the idea).

2) If no Central is found or more than one exists, dialog warnings will be issued. The Central file folder will open in Explorer so you can investigate the problem immediately.

3) The discipline is evaluated (from # above) and if the input is not as expected, you will be warned and the script will terminate. The Central file folder is opened in Explorer so you can investigate the problem immediately.

4) Local files will be created in C:\Revit Local Files\XXXXX #VV\ so if the folder does not exist, the script will create it. It will also automatically create backups of your local files just in case you might need one (like if the Central becomes corrupt). So first it will delete the last backup and place it in the Recycle bin (it will stay there until you empty your trash). Then it renames your local file and appends “_BAK” to the filename, copies the Central file to this folder, and removes “central” from the name and replaces it with your Windows username (Ex: 123456789-Project-A08_DBaldacchino.rvt).

5) Check if the required Revit flavor is installed. If not, it will give you the option to open the file with the Revit flavor you have installed on your PC (Ex: it will use Revit Structure 2008 to open an Architectural file). If no Revit is installed, it will let you know and ask you to contact IT (niiiiiice!), after which the script will terminate.

6) The username in the Revit.ini is deleted to prevent problems down the line (you've all experienced having two people working on a project with the same username and one of them complaining they cannot STC, right?!). This ensures that when Revit opens, the username will be set to your Windows username. If multiple flavors of Revit are installed, only the ini file of the discipline that you’re trying to use will be edited.

7) The script will now evaluate what command line/switch was sent through the shortcut. It recognizes "detach" or "worksets" (not case sensitive). In the "Target" field of your shortcut, leave a space at the end and type "detach" or "worksets". If you type anything else, the script ignores it and opens the local file as if no command was sent. So for example your shortcut target would look like this: "\\servername\Projects\ABC\Central\test_A08-Central.rvt" worksets. In this case, the script will write a custom journal called "select_ws.txt" in your journal folder and fire it up in a new instance of Revit. If the command line parameter was detach, a journal called "detach.txt" would be written and used. The script still makes a copy of the central file as a precaution when detaching. Note that currently there is no way to run a journal in an already running Revit session through AHK, so using one of the two switches will cause a new instance of Revit to open.

8) If there is no command line parameter (or an unrecognized one) in the shortcut, the script proceeds as before. First it checks if Revit is already running. If it is, the session will be activated and the local file will start opening. If not, a new session is fired up and the local file starts to open.

9) When the annoying dialog shows up (that this Central has been copied….), it is automatically dismissed, thus rendering the whole process entirely transparent.

Streamlining Local File creation