Thursday, 27 November 2008

Accessing schedules with the Revit API

I appreciate you may have excitedly arrived here from a successful search on Google, wondering how you use the Revit API with schedules. Well I'm afraid its bad news. You can't.

In the new CADsmart Revit skills assessment we wanted to assess a user's ability to create schedules as specified, but met a dead end with a support request on the ADN confirming that with schedules most commands are disabled, and that there is no API that allows access to any cell values in a schedule.

I'm hoping that this might be resolved with the next release. For the moment our assessment asks the user to export the schedule to a delimited text file so our code can access it, which is perfectly legitimate, but a step I'd rather do without.

Copy versus Array

It came to my attention recently that two different methods of placing an object in what should be the same places actually might end in slightly different results.

I'll explain by way of example. I had an office space into which I imported a .dwg of a cluster of desks. This instance was to be copied 3 further times and the copies were to be placed 3000mm apart, like this:



I did it the slightly laborious way by copying and moving. My clearly much cleverer colleague went for the more efficient array option. When I came to analyze the files using the BoundingBox property I discovered that what we ended up with were ever so slightly differently placed instances. And by ever so slightly I mean a different value in the 11th decimal place.

OK so perhaps I'm picking at straws here, but it had a serious impact on the reliability of what I was trying to do, which was to extract data as strings from two files to two databases, and compare this data looking for precise matches.

My solution was to use 

CDbl(value).ToString("#.000")
 

throughout, as I realised that such accuracy simply isn't required for my purposes.

But why does Revit do this? My guess is its simply a by-product of rounding in Revit's array code, or cumulative rounding from my clumsier but accurate moving and copying. I haven't delved any further, but I would hope if its the former that its not cumulative with the size of an array, as this would mean greater inaccuracies the more objects that are arrayed.

Monday, 24 November 2008

Opening a file in Revit

A simple place to start!

A fundamental requirement of some of the software I build is to open Revit files, present them to the user, ask the user to do some things to it, save and close the file, and then open another. Trying to open a Revit file is where I started many months back and boy was I disappointed; I wondered at this point if the API was going to be able to meet any of our needs. Perhaps my expectations were too high having worked with the mature AutoCAD API.

You can indeed open existing Revit files using the following:

Application.OpenDocumentFile(filename)


But this doesn't present the file to the user. You can't see it or access it, the file is waiting to be altered programatically, not by a human.

Apparently this functionality is on the wish-list, having been requested multiple times, so until then if you need to open a file for a user, you need to 'botch' it by asking Windows to open it:

Process.Start(filename)


Assuming the host machine knows what to do with a .rvt file, then your file will open up into Revit. And then you can use ActiveDocument to manipulate/save/close etc.