A Big Thank You

Last week, I was fortunate enough to attend Autodesk's Revit Structure 'Gunslingers' Event at their  development office in Krakow, Poland.

I would like to extend a massive thank you to Krzysztof and the team for their warm hospitality and for giving some of us the opportunity to get a glimpse and test new features, plus a valuable insight into understanding some of the sweat and tears that go into making Revit Structure what it is.

Update on Revit Family Parameters

I have heard back from Autodesk regarding the post below. It seems the behaviour described is not by design.
They are looking into it.

So I guess ........  Watch this space.

Revit 2014 Family Parameters - Sneaky Sneaky

I can't seem to find anything that lists this change, but this is a new one on me and could cause some upset generally, which is why I'm giving a heads up

Up until now, it has always been possible to mix different case parameters of the same name in a family. You could have a parameter called 'T' and one called 't' and it would sit very happily.

It now appears to be a different case in Revit 2014 and this has been swept away. It's not actually apparent with existing families until they are loaded into a project, taking you from this:

 

 



 

 

to this:

 

 

 

 

 

 

In hindsight, it's probably not best practice to have parameters named in this way. I'm guessing we'll just have to take our medicine and get on with it!



Worksets Hopping About a Bit?

When using a workshared file, we've found that on occasion, the active workset seems to change itself for no apparent reason. This particular quirk has always stumped us. Recently however, we have got to the bottom of this. I'm not entirely sure if this is a bug or by design, but the following is the behaviour that causes this to happen

In this scenario. Worksharing is enabled and 'Workset1' & 'Shared Levels and Grids' are created automatically. In addition, I have added a workset called 'A'

'Workset1' is the active workset. Note the following rules:

• On opening the workset dialogue, the Active Workset combo box always has initial focus
• The Active Workset combo box can only be populated by open worksets

Now we decide that we want to close 'Workset1'. On leaving the Workset dialogue, everything is normal and 'Workset1' is still listed in the main Active Workset box at the bottom of the main screen

Now we want to re-open 'Workset1', so we go to the workset dialogue. Under the two rules above, Revit jumps straight to the active workset combo box and says "Hang on, 'Workset1' isn't open, so it's not in the list. Therefore I will leap quick smart to the first entry in the list, in this case 'A'". 

Because the user's focus is on re-opening 'Workset1' in the table below, this sleight of hand by Revit is easily missed, resulting in the following

So the moral of the story is to remember to set back the active workset immediately after. Hope this helps

Type Catalogue Addendum

I posted back in October a tip for editing Type Catalogues from within Revit

A slight problem with this is sometimes it doesn't work and the batch script returns:

'CMD.EXE was started with the above path as the current directory. UNC paths are not supported. Defaulting to Windows directory.'

By adding the following lines to the top of the script, this will solve this:

%~d0
cd %~p0

From what I can see, this is caused by linked files that have UNC pathnames as opposed to drive mapped. When the Revit model is opened and the links loaded, if the last loaded link has a UNC path, the current directory is set at that UNC path and the script won't run. The lines above pull the drive letter of the running batch script and reset the path