The Building Coder

Revit Family Creation API Labs

The handouts and presentation for my Autodesk University family API session are finally done, as well they should be, since they are due to be submitted by today. The last part I worked on was to add more documentation on the family API labs to the handout document. I think this overview will be of interest here as well. The family API labs were originally created and documented by Mikako Harada, the ADN AEC workgroup lead, so all of the material presented here is due to her. Talking about that prompts me to mention the webcasts where this material was first used:

ADN webcast registration statistics

Most of the material that I am presenting at AU was originally prepared for webcasts on the Revit Family API and MEP API and then posted to this blog as well. Mikako just sent around some statistics on the numbers of registrations for the various webcasts held by the Autodesk Developer Network this year. The overview of all webcasts and other training classes is available online from the Autodesk Developer Network API training schedule. All in all, we presented on 25 different topics and had a total of 1576 attendees registered. The absolute leader in the number of registrations was the Revit API webcast with 250, followed by the Inventor API with 100. The Revit family and MEP API webcasts were also pretty popular with 75 and 64 respectively, so the three Revit webcasts together attracted 389 out of 1576 registrations or about 25%. This just goes to show that the Revit API is an important and popular topic.

Family API Labs: Creating an Example Family

Returning to the Revit Family API Labs, they are a collection of exercises which introduce you step by step to the creation of a column family. The objective is to learn the basics of the family API. The labs start at zero and proceed through the absolute beginning steps up to slightly more advanced aspects. Here are the four steps of increasing complexity covered:

1. Define a rectangular profile column family.
2. Define an L-shaped profile column family.
3. Add formulae and materials.
4. Add visibility control.

The full Visual Studio solution and projects, source code, detailed documentation and instructions for each step are included separately for both C# and VB. Here is an overview of the main files and directories:

• rfa_labs.sln – common C# and VB Visual Studio solution file
• cs – C# source code directory
  • LabsCs.csproj
  • 1_ColumnRectangle.cs
  • 2_ColumnLshape.cs
  • 3_ColumnFormulaMaterial.cs
  • 4_ColumnVisibility.cs
  • Util.cs
• csdoc – C# documentation and detailed step-by-step instructions directory
  • Family Lab1 - Create Rectangular Column_CS.rtf
  • Family Lab2 - Create L-Shape Column_CS.rtf
  • Family Lab3 - Add Formula and Material_CS.rtf
  • Family Lab4 - Add Visibility Control_CS.rtf
• vb – VB source code directory
  • LabsVb.vbproj
  • 1_ColumnRectangle.vb
  • 2_ColumnLshape.vb
  • 3_ColumnFormulaMaterial.vb
  • 4_ColumnVisibility.vb
• vbdoc – VB documentation and detailed step-by-step instructions directory
  • Family Lab1 - Create Rectangular Column.rtf
  • Family Lab2 - Create L-Shape Column.rtf
  • Family Lab3 - Add Formula and Material.rtf
  • Family Lab4 - Add Visibility Control.rtf

The source code and instruction documents are part of the Family API webcast materials. For your convenience, I am including them here as well.

The following summary provides a high-level overview of the implementation. Detailed information and step-by-step instructions are provided in the source code comments and the dedicated csdoc and vbdoc documents.

Lab 1 – Create Rectangular Column

The first lab demonstrates how to implement the following four essential basic steps for creating a new family:

1. Check the family context and category.
2. Create a simple solid using extrusion.
3. Set alignments.
4. Add types.

It makes use of the following classes and methods:

doc.IsFamilyDocument
doc.OwnerFamily.FamilyCategory.Name
doc.FamilyCreate.NewExtrusion()
doc.FamilyCreate.NewAlignment()
familyMgr = doc.FamilyManager
familyMgr.NewType()
familyMgr.Parameter(); familyMgr.Set()

Here is an overview of the four steps listed above in slightly greater detail:

1. In the first lab, we create a simple rectangular column family defining three column types with different dimensions. Before proceeding with the definition of the geometry and types, we need to ensure that we are working in a family template file and the correct family category. The document provides a property IsFamilyDocument to check the former, and the owner family category gives us the category of the template file.
2. Creating the geometry is easily achieved by defining a rectangular profile in the XY plane and extruding it using the NewExtrusion method. When creating the geometry, we need to account for the Revit database units and convert all our length measurements to feet.
3. One method to drive the geometry parametrically is to specify alignments between certain parts of the geometry and reference planes. In this very simple case, the template file already provides six reference planes for the upper and lower levels and the right, left, front and back faces, and we have six corresponding faces on the column. We need to specify alignments between these reference planes and the corresponding faces of our solid extrusion. This is done by identifying the matching pairs of solid face and reference plane and calling NewAlignment for each. In this simple case, the solid faces can be identified by their normal vectors and the reference planes by their names. In a more complex case, such as the next example in lab 2, we may have to create the reference planes ourselves, and use more complex algorithms to identify the reference planes and the solid geometry faces to associate with each other.
4. Finally, we create a few sample types for the family. In this simple case again, the template file already defines the parameters that we require for this, namely Width and Depth. Lab 2 will demonstrate how to define our own new parameters. Since the parameters are given, all we need to do is access the FamilyManager object and use its AddType and get_Parameter methods to specify the types to create and their dimensions.

Further in-depth details on the process and source code snippets to achieve each of these four steps is given in the separate documents 'Family Lab1 - Create Rectangular Column.rtf' in the csdoc and vbdoc subdirectories for C# and VB, respectively.

Lab 2 – Create L-Shaped Column

The second lab builds on the first to define a column with a slightly more complex L-shaped cross section profile. Due to this, the predefined reference planes and parameters provided by the template file are not sufficient to drive all aspects of the geometry, so we have to create our own additional ones. To be precise, we need reference planes, parameters and dimensions to determine and measure the thickness of the two 'legs' of the L shape.

Also, in the L-shaped column solid, the normal vector alone is not enough to identify all of the individual solid faces, so that algorithm needs to be refined as well. In our case, we use the reference plane associated with each solid face to identify it.

Finally, the lab also demonstrates adding new dimensioning to the family definition. The following steps are added to the existing ones:

• Add reference planes.
• Add parameters.
• Add dimensions.

The classes and methods used include:

doc.FamilyCreate.NewReferencePlane()
familyMgr.AddParameter()
doc.FamilyCreate.NewDimension()

Separate C# and VB versions of the detailed instructions, explanations, and source code snippets for this lab are provided by the document 'Family Lab2 - Create L-Shape Column_CS.rtf' in the csdoc and vbdoc subdirectories of the sample material.

Lab 3 – Add Formulae and Materials

In the third step, we further enhance the column family defined in the previous step by defining formulae for the L shape leg width parameters and by assigning a material to one of the family types.

• Add formulae.
• Add materials.

The classes and methods used include:

familyMgr.SetFormula()
pSolid.Parameter("Material")
familyMgr.AddParameter()
familyMgr.AssociateElementParameterToFamilyParameter()

The two parameters are defined as formulae so that the L shape leg width equals a quarter of the column width, and similarly for the depth. The key here is the family manager SetFormula method.

For the material, an instance parameter for the material group is added to the family and associated with the material parameter of the solid. Here, the key is the AssociateElementParameterToFamilyParameter method.

Again, separate C# and VB versions of the detailed instructions, explanations, and source code snippets for this lab are provided by the document 'Family Lab3 - Add Formula and Material_CS.rtf' in the csdoc and vbdoc subdirectories of the sample material.

Lab 4 – Add Visibility Control

Performance is a critical aspect of building family content, and significant performance improvements can be achieved by making use of the visibility settings accessible for each element in a family through the FamilyElementVisibility class, which can define which levels of detail and which types of views it appears in. That is the focus of this final lab, which implements the following:

• Implement a single line representation for the column in coarse view:
  • Single symbolic line representation in plan view.
  • Single model line representation in model view.
• Set the visibility control so that the single line representation is used in coarse view.

The classes and methods used include:

doc.FamilyCreate.NewSymbolicCurve()
doc.FamilyCreate.NewModelCurve()
FamilyElementVisibility(FamilyElementVisibilityType.ViewSpecific/Model)
FamilyElementVisibility.IsShownInFine, etc.
pLine.SetVisibility(pFamilyElementVisibility)

The detailed documentation and C# and VB code snippets for this lab are provided by the document 'Family Lab4 - Add Visibility Control_CS.rtf' in the csdoc and vbdoc subdirectories of the sample material.

Dismiss Dialogue using Windows API

I am often confronted with unwanted dialogues popping up when I am trying to drive some application programmatically. In Revit, many dialogues raise an event when they are displayed and allow us to implement an add-in application to handle them automatically. Unfortunately, as noted in the discussion on using the DialogBoxShowing event, some of the Revit dialogues do not raise such an event when displayed, so we cannot use the standard Revit API to handle or dismiss them.

Also, there are many other applications besides Revit that I am trying to drive programmatically, and they often do not provide any API at all, let alone a possibility to disable or automatically handle any of their user interface message boxes.

Furthermore, there may be situations within Revit where the DialogBoxShowing event is raised and the dialogue can be handled, but this causes problems within Revit. For instance, one developer reports that the DialogBoxShowing event handler crashes when trying to hide the dialog using an override result after the dialogue has been triggered due to closing a transaction using EndTransaction. In that case, Revit says that the document was modified outside the transaction and generates an exception.

Question: What can I do to automatically handle or dismiss dialogues in these situations?

Answer: As said, most Revit messages can be caught and responded to programmatically by a plug-in application by handling the Revit dialogue box DialogBoxShowing event, and source code and a description for exploring this kind of situation is provided in the discussion mentioned above.

The easiest way to find out whether you can use this event to handle your specific dialogue is to:

• Implement and install the dialogue box handler.
• Set a breakpoint in the event handler.
• Reproduce the situation in which the dialogue is displayed by Revit.
• Check whether the event was fired or not.

Inside the event handler, the debugger will show you what data is being passed in and thus how you can identify this dialogue in your code for automatic processing.

On the other hand, if the specific dialogue you are confronted with is not accessible in the Revit call-back, or you are dealing with some completely different application lacking the DialogBoxShowing event, I will explain below how you can use the .NET framework in C# and VB or the native Windows API to handle it automatically instead. In short:

• In the .NET framework, you can use methods from the WinApi.User32 namespace like FindWindow, EnumWindows, and GetWindowText from inside a System.Timers.Timer instance to determine that a certain window is being displayed by the Windows OS and close it using WinApi.User32.SendMessage.
• In the native Windows API, similar functionality can be achieved by creating a hook in the main Revit window with SetWindowsHookEx and sending a WM_CLOSE or some other message to a dialogue when it is displayed.

.NET Dialogue Clicker in C#

Here is the C# source code and entire Visual Studio solution for a little utility named JtClicker that I have used many times in the past and is very near and dear to me. It was especially useful during my time in Autodesk Consulting, when we were always automating a large number of different applications which unfortunately were equipped with user interfaces as well as APIs. The user interfaces would often insist on popping up various irritating dialogue boxes which could not be suppressed programmatically.

The solution that I developed for this is a Windows API based stand-alone command-line utility that simply sits and waits for a dialogue with certain characteristics to appear. If and when such a dialogue is displayed, the utility immediately dismisses it in a certain predefined way.

This solution I implemented is thus a generic dialogue clicker in C# using the .NET framework to access the underlying Windows API. In fact, it has nothing at all to do with the Revit API.

Since every dialogue is different, we need a lot of flexibility in the details of identifying and handling various specific dialogues. The two main requirements for a high degree of flexibility are:

• How to identify that the dialogue we are interested in has been displayed.
• How the dialogue should be dismissed, once it has been identified.

Therefore, this utility will always require some tweaking before use and is only useful in source code format for that reason. Check out the source code and the following discussion I had on that topic with my colleague Greg Wesner of Autodesk Consulting for details:

.NET Dialogue Clicker in VB

I was prompted to dive into this subject again recently by Greg Wesner of Autodesk Consulting. Here is an example of my interaction with him when he made use of JtClicker, in which Greg also provides a VB version of the original C# implementation:

[Q] I heard you might have a sample of code for how to 'spoof' a click of the OK button in a windows dialog. Specifically, I need to launch the options dialog in AutoCAD and then close it immediately with an OK click, i.e. I cannot cancel it. Closing the dialog with OK results in AutoCAD refreshing all the paths. Launching is obviously no problem but the OK click is tougher. I'm working in VB.NET, so a .NET sample is really what I'm after.

[A] Yes, I am appending my little dialogue clicker to this mail. There are comments inside form1 explaining its function and usage. It searches for a dialogue using certain characteristics. Once the dialogue appears, it sends windows messages to it in EnumChildProc. You will need to tweak those messages to hit the button you need.

[Q] Thanks Jeremy. That was exactly what I needed. Hooked it all up and it is working great.

[A] Very glad to hear that it works for you! Have you changed or improved anything in it? If so, could you show me what you fixed or improved?

[Q] Well, I wish I could say that I improved on it, but you pretty much had all the parts I needed. I was actually able to 'dumb' it down some because I could hard code the dialog name "Options" and the button "OK". I also tested that "Options" and "OK" would dismiss the Options dialog in AutoCAD as expected with the original project files you sent.

I was hoping that I wouldn't need to use the timer and would be able to just make the call straight to EnumWindows. But that didn't work because the Options dialog doesn't actually come up until my function returns. So I had to use the timer as well to delay the call to EnumWindows. I found dropping the interval to 300ms was better though, because you barely see the dialog come up. I call Timer.Stop() as soon as I find the button I'm looking for, because I will only need it to happen once every time the dialog comes up. I am thinking about adding some defensive code that counts how many times we call EnumWindows in the Timer, and if we go above a certain number of times (maybe 500), we stop trying. That way if anything happens and the Options dialog never comes up, we don't chew up CPU cycles forever.

One thing I did do was translate WinApi.vb and the EnumWindowsProc() and EnumChildProc() methods to VB. So I could pass that on to you in case you get requests for this in VB. First, here is the module WinApi.vb providing access to the Windows API calls:

Imports System
Imports System.Runtime.InteropServices
Imports System.Text
 
Module User32
  Delegate Function EnumWindowsProc(ByVal hWnd As Integer, ByVal lParam As Integer) As Boolean

  <DllImport("user32.dll", CharSet:=CharSet.Unicode)> _
  Function FindWindow(ByVal className As String, ByVal windowName As String) As Integer
  End Function

  <DllImport("user32.dll", CharSet:=CharSet.Unicode)> _
  Function EnumWindows(ByVal callbackFunc As EnumWindowsProc, ByVal lParam As Integer) As Integer
  End Function

  <DllImport("user32.dll", CharSet:=CharSet.Unicode)> _
  Function EnumChildWindows(ByVal hwnd As Integer, ByVal callbackFunc As EnumWindowsProc, ByVal lParam As Integer) As Integer
  End Function

  <DllImport("user32.dll", CharSet:=CharSet.Unicode)> _
  Function GetWindowText(ByVal hwnd As Integer, ByVal buff As StringBuilder, ByVal maxCount As Integer) As Integer
  End Function

  <DllImport("user32.dll", CharSet:=CharSet.Unicode)> _
  Function GetLastActivePopup(ByVal hwnd As Integer) As Integer
  End Function

  <DllImport("user32.dll", CharSet:=CharSet.Unicode)> _
  Function SendMessage(ByVal hwnd As Integer, ByVal Msg As Integer, ByVal wParam As Integer, ByVal lParam As Integer) As Integer
  End Function

  Public BM_SETSTATE As Integer = 243
  Public WM_LBUTTONDOWN As Integer = 513
  Public WM_LBUTTONUP As Integer = 514
End Module

Here is the main application:

Private timer1 As Timer
Private timer_interval As Integer = 300  ' in milliseconds so 1000 = 1 second
Private timer_attempts As Integer

Public Function EnumWindowsProc(ByVal hwnd As Integer, ByVal lParam As Integer) As Boolean
  Dim sbTitle As New StringBuilder(256)
  Dim test As Integer = User32.GetWindowText(hwnd, sbTitle, sbTitle.Capacity)
  Dim title As String = sbTitle.ToString()
  If title.Length = 0 Then
    Return True
  End If
  If title = "Options" Then
  Else
    Return True
  End If
  User32.EnumChildWindows(hwnd, New User32.EnumWindowsProc(AddressOf EnumChildProc), 0)
  Return False
End Function

Public Function EnumChildProc(ByVal hwnd As Integer, ByVal lParam As Integer) As Boolean
  Dim sbTitle As New StringBuilder(256)
  User32.GetWindowText(hwnd, sbTitle, sbTitle.Capacity)
  Dim title As String = sbTitle.ToString()
  If title.Length = 0 Then
    Return True
  End If
  If title = "OK" Then
  Else
    Return True
  End If
  User32.SendMessage(hwnd, User32.BM_SETSTATE, 1, 0)
  User32.SendMessage(hwnd, User32.WM_LBUTTONDOWN, 0, 0)
  User32.SendMessage(hwnd, User32.WM_LBUTTONUP, 0, 0)
  User32.SendMessage(hwnd, User32.BM_SETSTATE, 1, 0)
  timer1.Stop()
  timer1 = Nothing
  Return False
End Function

Public Sub timer1_Tick(ByVal sender As Object, ByVal e As EventArgs)
  'timer_attempts is a failsafe to make sure that if for some reason the Options dialog
  ' never comes up, we don't keep looking for it forever. We usually find the dialog on the
  ' first few tries, so if it doesn't come up in about the first minute, we give up
  If timer_attempts < 300 Then
    User32.EnumWindows(New User32.EnumWindowsProc(AddressOf EnumWindowsProc), 0)
  Else
    timer1.Stop()
  End If
  timer_attempts += 1
  Debug.Print(timer_attempts.ToString())
End Sub

' The options dialog will not come up until our function returns, so we setup a timer
' that will check every 300 milliseconds to see if it can find the dialog. Once it finds
' the dialog and clicks OK, it stops.
Public Sub closeOptionsDialog()
  timer_attempts = 0
  If timer1 Is Nothing Then
    timer1 = New Timer()
  End If
  timer1.Interval = timer_interval
  AddHandler timer1.Tick, New EventHandler(AddressOf timer1_Tick)
  timer1.Start()
End Sub

If the source code lines are truncated by your browser, you can copy and paste the text to a text editor.

Using a native Windows API Hook

The JtClicker dialogue clicker application described above is using the .NET framework to identify the dialogue and send messages to dismiss it. Since the Win32 portion of the .NET framework is just a wrapper around native Windows API calls, the same functionality can also be implemented more directly using the native API.

Here is a report on using a Windows hook to dismiss a dialogue triggered by closing a Revit transaction.

I investigated using a hook, and this is the solution :-) I created a hook in the main Revit window with SetWindowsHookEx and send messages to the dialogue when it is detected. Initially I sent a WM_CLOSE message to close it, later I changed it to click the OK button instead. This works really well, even if the dialog is shown when ending a transaction, in which case the DialogBoxShowing event generates an exception if I try to hide the dialog with OverrideResult.

My hook function is:

private static void ProcessWindow(
  IntPtr hwnd )
{
  if (App.OcultarMensajesRevit)
  {
    // Buscamos el botón de aceptar y lo pulsamos.
    int ID_OK = 1;
    IntPtr hwndOk = Win32.Functions.GetDlgItem(
      hwnd, ID_OK );

    if (hwndOk != IntPtr.Zero)
    {
      Win32.Functions.SendMessage(
        hwndOk, (uint)Win32.Messages.WM_LBUTTONDOWN, 
        (int)Win32.KeyStates.MK_LBUTTON, 0 );

      Win32.Functions.SendMessage(
        hwndOk, (uint)Win32.Messages.WM_LBUTTONUP, 
        (int)Win32.KeyStates.MK_LBUTTON, 0 );
    }
    //Win32.Functions.SendMessage(
    //  hwnd, (uint)Win32.Messages.WM_CLOSE, 0, 0 );
  }
}

App.OcultarMensajesRevit is a variable I created to enable dialogue auto closing. Instead of sending a WM_CLOSE message to the window to cancel it, I observed I needed to push the OK button for all things to work, so I search for that button and send it a button down and a button up message to simulate a mouse click.

To connect the hook function, I used the WindowInterceptor class I found at CodeProject.

Then I add the following in the Startup event of my application:

Process process = Process.GetCurrentProcess();

IntPtr hwnd = process.MainWindowHandle;

App._windowsInterceptor = new WindowInterceptor(
  hwnd, ProcessWindow );

To clean up at the end, I add the following on shutdown:

App._windowsInterceptor.Stop();

Document Elements

We have already used the Document.Elements property a couple of hundred times in previous posts to this blog, so this explanation is rather belated, but addresses a question that does keep on popping up from time to time anyway:

Question: How can I access the Document.Elements property in C#?

The Revit help document lists the property named Document.Elements, stating that it is an overloaded property providing access to a set of elements from the document. The overloads are listed as

• Elements: Provides access to all elements within the document.
• Elements( Filter ): Provides access to all elements which satisfy specified filter.
• Elements( Type ): Provides access to all elements of specified type.
• Elements( Filter, ElementArray ): Collects all elements which satisfy specified filter.
• Elements( Filter, ICollection of Element ): Collects all elements which satisfy specified filter.
• Elements( Type, ElementArray ): Collects all elements which satisfy specified type.
• Elements( Type, ICollection of Element ): Collects all elements which satisfy specified type.

However, when I try to access these properties in C#, the Visual Studio compiler reports an error and says that they do not exist. How can I access these properties in C#?

Answer: You can look at the C# source code generated automatically by the definition of the Document class by Visual Studio, by positioning the cursor over the Document type and pressing F12. This shows a completely different list of overloads:

• public ElementIterator Elements;
• public ElementIterator get_Elements( Filter );
• public ElementIterator get_Elements( Type );
• public int get_Elements( Filter, ElementArray );
• public int get_Elements( Filter, ICollection );
• public int get_Elements( Type, ElementArray );
• public int get_Elements( Type, ICollection );

As you can see, only the Elements property with no filter or type argument is available using the name given in the help file. The other Document.Elements members are considered to be methods, not properties, and have therefore been automatically decorated with the accessor prefix "get_". To call them, you need to prepend "get_" and obviously also provide the required arguments.

Question: How can I access the Document.Elements property in VB?

I have converted some C# sample the code to VB but have an error with a function in the line

  m_doc.getElements(viewFilter, views) 

The error states that .GetElements is not a member of Autodesk.Revit.Document, although I have defined m_doc as an Autodesk.Revit.Document.

Answer: You can use the Visual Studio Intellisense functionality or the object browser to determine the real name of the method you are trying to invoke in whatever language you prefer to use.

The method or property you are accessing is called Elements in the Revit API help. In C#, it is accessed using the call

  m_doc.get_Elements(viewFilter, views);

In VB, you have to drop the "get_" prefix, so the call is

  m_doc.Elements(viewFilter, views)

Reply: Thanks for the response. I did try with Elements, but this causes an error saying "property access must assign to the property or use its value", as it is returning an Integer. This problem goes away if I use

  Dim i as Integer = m_doc.getElements(viewFilter, views)

What are we using the return value from this line for anyway?

Answer: Oops, yes, right you are. The return value of these properties is the number of elements matching the specified criteria.

In VB, this is a read-only property, and the VB syntax requires you to make use of it as such. This means that you must read the value returned by the property, regardless of whether you make use of it or not.

Maybe this is part of the reason why these members are considered methods instead of properties in C#. In C#, you are not forced to read the return value, but you can, if you like.

Room Boundary Location

We already had a look at enabling the room volume computation in C#. Here is a closely related question that also prompted me to implement something similar in VB for a change.

Question: Could you please provide some VB.NET code showing how to set the Autodesk.Revit.Rooms.BoundaryLocationType in the document, for instance to 'WallCenter'?

Answer: The boundary location type is applied when calculating the room volume. These settings are defined by the document settings volume calculation options. The post mentioned above discusses how to access and modify these settings.

I implemented a VB.NET sample application RoomBoundaryLocation for you to demonstrate this in VB as well. Here is the mainline code of its Execute method:

Public Function Execute( _
  ByVal commandData As ExternalCommandData, _
  ByRef message As String, _
  ByVal elements As ElementSet) _
  As CmdResult _
  Implements IExternalCommand.Execute

  Dim app As Application = commandData.Application
  Dim doc As Document = app.ActiveDocument

  Dim opt As VolumeCalculationOptions _
    = doc.Settings.VolumeCalculationSetting _
      .VolumeCalculationOptions

  opt.VolumeComputationEnable = True

  opt.RoomAreaBoundaryLocation _
    = Rooms.BoundaryLocationType.WallCenter

  doc.Settings.VolumeCalculationSetting _
    .VolumeCalculationOptions = opt

  Dim volumes As List(Of String) = New List(Of String)
  Dim els As ElementSet = doc.Selection.Elements

  Dim e As Autodesk.Revit.Element
  For Each e In els
    If TypeOf e Is Room Then
      Dim room As Room = CType(e, Room)
      volumes.Add(room.Volume.ToString("0.##"))
      'Else
      '  volumes.Add("Not a room")
    End If
  Next

  If 0 = volumes.Count Then
    message = "Please select some rooms."
  Else
    Dim s As String = _
      +"Selected room volumes in cubic feet: " _
      + String.Join(", ", volumes.ToArray()) _
      + "."
    MsgBox(s)
  End If

  Return CmdResult.Failed
End Function

Here are some sample rooms and spaces selected in the Revit user interface:

This is the resulting dialogue displayed by running the command:

Here is the complete Visual Studio solution RoomBoundaryLocation implementing the new command.

DWG Export Filename

Here is a question handled by Joe Ye that I thought might be of general interest.

It makes use of the Revit SDK sample ImportExport converted to VB.NET. We mentioned the issue of converting Revit SDK samples from C# to VB in one post, and Adam Nagy later presented a more complete port.

Question: I am making an application to export Revit views to DWG files. I used the ImportExport sample converted to VB.NET as a basis. I am having trouble defining filenames other than the built-in solution. The syntax for defining the DWG filename for a given view seems to be:

[FileName] & " - " & [ViewType] & " - " & [ViewName] 

The filename can be changed, but the other substrings seem to be hardcoded, or at least I can't find where they are defined. I would like the FileName and ViewType substrings to be optional and maybe replaced by some other project defined prefix. Is this possible through the API?

If not, a workaround could be to rename the DWG files afterwards, but I hope to avoid that.

Answer: In this case, you are using one of the overloads of the Export method taking four arguments, the fourth of which specifies the type of export required. The first three are folder, name, and views:

• folder: the output folder into which the files will be exported.
• name: either the name of a single file or a prefix for a set of files. If null or empty, automatic naming will be used.
• views: a selection of views to be exported. If null or empty, only the active view will be exported.

As the documentation says, the exported DWG file name is in fact generated using a hardcoded algorithm inside Revit if the view set contains more than one single element.

If only one view is specified, then the filename string constructed from three substrings provided by specific variables is used. It is defined in the module ExportData.vb, in the Initialize function:

Private Sub Initialize()
  ' The directory into which the file will be exported 
  Dim dllFilePath As String _
    = Assembly.GetExecutingAssembly().Location
 
  m_exportFolder = Path.GetDirectoryName(dllFilePath)
 
  ' The file name to be used by export 
  Dim docTitle As String = m_activeDoc.Title
 
  Dim v As View = m_activeDoc.ActiveView
 
  Dim viewName As String = v.Name
  Dim viewType As String = v.ViewType.ToString()
 
  m_exportFileName = docTitle _
    + "-" + viewType _
    + "-" + viewName _
    + "." + getExtension().ToString()
 
  ' Whether current active view is 3D view 
 
  If v.ViewType = Enums.ViewType.ThreeD Then
    m_is3DView = True
  Else
    m_is3DView = False
  End If
End Sub

Therefore, you can easily make FileName and ViewType optional or replace them by some other prefix. Simply change the string values in the definition of m_exportFileName as you please, for instance like this:

m_exportFileName = docTitle + "-" + “aaaa” + “.” + getExtension().ToString

Note that changes to the specified filename have no effect if more than one view is given in the third argument to the Export method. If the third argument includes more than one view, Revit will automatically name each exported DWG file using a hard-coded rule including the second argument to the Export method as a prefix. If the third argument includes just one single view, then the file name passed in is used. So the workaround to use your own naming rule is to export only one view at a time. In case of multiple views, you can export them one by one in a loop.

This information obviously also applies to the other overloads of the Export method taking a ViewSet argument, including export to:

• DGN
• DWF2D
• DWF3D
• DWFX2D
• DWFX3D
• DWG
• FBX

Thank you very much Joe for this answer!

Porting from C# to VB.NET

Yesterday, we mentioned Kean Walmsley's recent post on converting between C# and VB.NET. In response to the closely related frequently asked question on porting the Revit SDK samples provided in C# to VB.NET, here is an exhaustive study of the topic by Adam Nagy.

Question: I'm looking at the Revit SDK samples, but many of them are in C#. Since I am a VB.NET programmer I'd prefer to use a VB.NET version. I tried to convert them myself but ran into some problems. Could you tell me the exact steps I could follow?

Answer: The best thing is to show it through an example. Let's port the ImportExport sample to VB.NET. The attached sample only contains the DWG Import/Export part.

1. Open the "ImportExport" C# project.
2. Open another instance of Visual Studio.
3. In the second instance, create a VB.NET "Class Library" project with "Name" = "VB.NET", "Location" = "[Revit SDK]\Samples\ImportExport" and "Create directory for solution" unticked. This way, all the project content will automatically be placed in the "[Revit SDK]\Samples\ImportExport\VB.NET" folder instead of e.g. "[Revit SDK]\Samples\ImportExport\VB.NET\ImportExport" folder.
4. Select the "VB.NET" project in the "Solution Explorer" and then click on it again so you can rename it to "ImportExport".
5. Select the Solution in the "Solution Explorer" (top node) and in the "Properties" window change its "(Name)" to "ImportExport".
6. Go to Project > Properties > Application and set "Assembly Name" to "ImportExport" and "Root namespace" to "".
7. Right-click on the project in the "Solution Explorer" and select "Add reference..."; on the "Browse" tab, navigate to "[Revit install folder]\Program\RevitAPI.dll" and click "OK".
8. Click the "Show All Files" button in the top of the "Solution Explorer", then select "References > RevitAPI.dll" and in the "Properties" window set "Copy Local" to "False".
9. Select "Class1.vb" and in the "Properties" window set "File Name" to "Command.vb". A dialog might pop up asking if you want to perform a rename in the project - click "Yes".
10. Copy all the content of Command.cs - just select Command.cs in the C# project, select its content (Ctrl+A), and copy it (Ctrl+C).
11. Now convert the code to VB.NET by using e.g. one of the online tools - http://www.developerfusion.com/tools/convert/csharp-to-vb seemed to work fine. Just paste (Ctrl+V) the code into the edit window on the site - if it already has some content in it, then first select all of that (Ctrl+A). Then click "Convert to VB.NET" and once the conversion is finished click "copy to clipboard".
12. Select all the contents of Command.vb (Ctrl+A) and replace it with the converted code, which has been copied to the clipboard (Ctrl+V). In case of interface implementations in VB.NET you need to explicitly define what interface function a given function implements - in C# it's not needed. So when you copied over the content of "Command.cs" to "Command.vb" then you need to insert "Implements IExternalCommand.Execute" at the end of the line of "Public Function Execute(...".
13. You have to go through all the other files and repeat the above steps.
14. To be consistent with the samples' structure either.
    1. replace "Namespace Revit.SDK.Samples.ImportExport.CS" with "Namespace Revit.SDK.Samples.ImportExport.VB.Net" in all "*.vb" files,
    2. or delete "Namespace Revit.SDK.Samples.ImportExport.CS" in all "*.vb" files (including Designer files) and set "Project > Properties > Application > Root namespace" to "Revit.SDK.Samples.ImportExport.VB.Net".
15. Now you can just copy "[Revit SDK]\Samples\ImportExport\CS\Revit.ini" to "C:\Revit SDK\Samples\ImportExport\VB.NET" and replace "Revit.SDK.Samples.ImportExport.CS.Command" with "Revit.SDK.Samples.ImportExport.VB.Net.Command" in it.

In case of simple code files, e.g. "MainData.cs" you just need to create a similar file

1. Right-click the VB.NET project in the "Solution Explorer" and select "Add > Class... > Common Items > Class" and set "Name" to "MainData.vb".
2. Copy all the content from "MainData.cs" and then paste its converted version into "MainData.vb" as we've done above with "Command.cs".

In case of form files, e.g. "MainForm.cs"

1. Right-click the VB.NET project in the "Solution Explorer" and select "Add > Windows Form..." and set "Name" to "MainForm.vb".
2. Since we earlier clicked the "Show All Files" button in the top of the "Solution Explorer", we can see that there is also a "Designer" file listed under "MainForm.vb" in the "Solution Explorer".
3. First copy the converted code of "MainForm.Designer.cs" to "MainForm.Designer.vb" - this will automatically copy all the controls and their event handlers over as well.
4. Right-click on "MainForm.cs", select "View Code", and copy the converted code to "MainForm.vb".

To retain the same project structure as in the original ImportExport sample, you can simply add folders to the VB.NET project: Right-click the project and select "Add > New Folder". You can also drag & drop files inside the project to reorganize them.

Thank you very much Adam for this detailed description!

A .NET Language Learning Resource

Since all Revit API programming is based on .NET, and the most accessible programming languages for creating .NET applications are C# and VB, we are occasionally asked how to get started with these. While we discussed the resources available for getting started with the Revit API itself, there is also a need to learn a .NET programming language in order to make efficient use of it.

Here is an enthusiastic endorsement from Jack Foster for some VB.NET training material. Jack is a long time LISP programmer who has been learning the core concepts of VB.NET while trying to use the AutoCAD.NET API. He never used VB or VBA before.

Good morning and I wanted to let you know that I found a website, in the UK no less, that has some great basic beginner's tutorials online that are free: http://www.homeandlearn.co.uk. Or you can purchase, as I did, a PDF e-book for the outstanding price of 5.49 pounds which is an absolute steal. I thought I would let you know in case you have some other beginners who need some easy to learn. I am very impressed with the detailed explanations that are provided.

I am doing pretty well with what you all taught me and have had to tweak and make additions but it is all working fine. Many times I have felt like going to Dev Help online but I have resisted and been able to figure it out myself and I learn more that way. There will be times when it will be essential to get your help. Please pass this on. There is also a Visual C# .NET course.

I have fiddled and googled and all kinds of links trying to find out something. Stumbled onto this website from googling and went to the tutorial on combo boxes and WOW. Right there step by step and very clearly explained was exactly what I needed to know. This is so much better than some books I looked at, and I even bought the Dummies VB.NET book. The cliché 'can't say enough about how good it is' would kind of apply here. Pass it on to anyone and check it out to make sure.

I have done AutoLISP for 20 years and I am still not good at it but I have done a lot of good things. VB.NET just totally dazzles me with what you can do. With AutoLISP I had reduced what took an hour down to five minutes. With VB.NET I have now reduced that hour task to about 15 seconds or less. That is mindboggling to me.

Converting Between C# and VB

We have repeatedly touched on the topic of converting between C# and VB, and I mentioned how I use the Reflector tool for this task, for example to convert Revit SDK samples. Kean Walmsley has also now explored this topic in some depth in this new post on converting between C# and VB.NET.

Selecting Model Elements

This morning I woke up really early. The hotel clock was set incorrectly, so when I woke up and looked at it, I thought I was much too late for my meeting. I jumped out of bed, grabbed and packed all my things and ran out of the room to the lobby, where I noticed that it seemed rather quiet outside and the light was very soft and special in the early morning. Up here in the north it does get light very early, though. At least I noticed my error before actually getting out into the street. Now I am unable to sleep, sitting in bed and writing this post.

The Revit API Introduction Lab 2-2 demonstrates how to select all model elements, i.e. elements which are visible on the graphics screen and represent physical parts in the building model. This lab is part of the sample code used to explain the basics of programming Revit in the Revit programming webcast. When updating this code for Revit 2010, I noticed that one change has occurred in Revit which causes this command to return incorrect results. First let us have a look at the original version which worked properly in Revit 2009, and then discuss the changes I made for 2010.

In 2009, we used the following helper method to select all model elements:

public static ElementSet GetAllModelElements(
  Application app )
{
  ElementSet elems = app.Create.NewElementSet();

  Geo.Options opt = app.Create.NewGeometryOptions();

  ElementIterator iter = app.ActiveDocument.Elements;
  while( iter.MoveNext() )
  {
    Element e = iter.Current as Element;

    if( !( e is Symbol || e is FamilyBase ) )
    {
      if( null != e.Category )
      {
        if( null != e.get_Geometry( opt ) )
        {
          elems.Insert( e );
        }
      }
    }
  }
  return elems;
}

It iterates over all elements in the active document and checks their class, category and geometry content to select the model elements. The selected elements are stored in a new element set, which is returned to the caller.

When asking the elements for their geometry, a geometry options instance must be provided. This argument cannot be null. Otherwise, an exception will be thrown. However, its detail level property and other properties may be left uninitialized.

The iterator type can be specified as either ElementIterator or IEnumerator. The iterator returned by the document Elements property is in fact an ElementIterator instance. This class is derived from the IEnumerator interface, and we only make use of the base class functionality, so an IEnumerator instance could be used just as well.

All the objects returned by the iterator are Autodesk.Revit.Element instances. It would be nice to know that we only need to check for certain specific types of objects, derived from the Autodesk.Revit.Element class, for example FamilyInstance and HostObject classes. Unfortunately, some Revit building model objects such as stairs are still represented in the API using the generic Autodesk.Revit.Element class, so this is not possible. Instead, we use the inverse approach of eliminating certain element types which are not used for building model objects, namely the Symbol and FamilyBase classes.

All building model objects have a valid category and non-empty geometry, so those properties can be used reliably.

However, in Revit 2010, running the same code suddenly returns a number of unexpected objects, even in an empty model.

Legend Component Geometry

The reason for the change in behaviour in Revit 2010 is that legend component objects now also return geometry. Since they are represented by Autodesk.Revit.Element instances, are not Symbol or ElementBase instances, and also have a valid category, they pass all the filters applied above in spite of not being model objects. Here is a list of the legend component elements returned in Revit 2010 in an empty model (copy to an editor to see the full line length):

There are 50 model elements:
  Name=Basic Wall : Generic - 150mm (Floor Plan); Category=Legend Components; Id=137075
  Name=Basic Wall : Interior - 138mm Partition (1-hr) (Floor Plan); Category=Legend Components; Id=137076
  Name=Basic Wall : Exterior - Brick and Block on Mtl. Stud (Floor Plan); Category=Legend Components; Id=137077
  Name=Basic Roof : Generic Roof - 300mm (Section); Category=Legend Components; Id=137078
  Name=Basic Roof : Generic Roof - 750mm (Section); Category=Legend Components; Id=137079
  Name=Basic Roof : Generic Roof - 500mm (Section); Category=Legend Components; Id=137080
  Name=Floor : Generic Floor - 400mm (Section); Category=Legend Components; Id=137081
  Name=Basic Ceiling : Generic (Section); Category=Legend Components; Id=137082
  Name=Basic Wall : Generic - 200mm (Floor Plan); Category=Legend Components; Id=137083
  Name=Basic Wall : Generic - 250mm (Floor Plan); Category=Legend Components; Id=137084
  Name=Basic Wall : Generic - 300mm (Floor Plan); Category=Legend Components; Id=137085
  Name=Basic Wall : Generic - 375mm (Floor Plan); Category=Legend Components; Id=137086
  Name=Basic Wall : Generic - 300mm Masonry (Floor Plan); Category=Legend Components; Id=137087
  Name=Basic Wall : Generic - 200mm CMU (Floor Plan); Category=Legend Components; Id=137088
  Name=Basic Wall : Generic - 150mm Masonry (Floor Plan); Category=Legend Components; Id=137089
  Name=Basic Wall : Exterior - EIFS on Mtl Stud (Floor Plan); Category=Legend Components; Id=137090
  Name=Basic Wall : Generic - 90mm Brick (Floor Plan); Category=Legend Components; Id=137091
  Name=Basic Wall : Interior - 79mm Partition (1-hr) (Floor Plan); Category=Legend Components; Id=137092
  Name=Basic Wall : Interior - 123mm Partition (1-hr) (Floor Plan); Category=Legend Components; Id=137093
  Name=Basic Wall : Interior - 135mm Partition (2-hr) (Floor Plan); Category=Legend Components; Id=137094
  Name=Basic Wall : Interior - 126mm Partition (2-hr) (Floor Plan); Category=Legend Components; Id=137095
  Name=Basic Wall : Exterior - Brick on CMU (Floor Plan); Category=Legend Components; Id=137096
  Name=Curtain Wall (Floor Plan); Category=Legend Components; Id=137097
  Name=Floor : Wood Joist 220mm - Wood Finish (Section); Category=Legend Components; Id=137098
  Name=Floor : Steel Bar Joist - VCT on LW Concrete  (Section); Category=Legend Components; Id=137099
  Name=Basic Roof : Wood Rafter 184mm - Asphalt Shingles (Section); Category=Legend Components; Id=137100
  Name=Basic Roof : Steel Truss - Insulation on Metal Deck- EPDM (Section); Category=Legend Components; Id=137101
  Name=Basic Wall : Foundation - 300mm Concrete (Floor Plan); Category=Legend Components; Id=137102
  Name=Basic Wall : Retaining - 300mm Concrete (Floor Plan); Category=Legend Components; Id=137103
  Name=Basic Wall : Generic - 200mm - Filled (Floor Plan); Category=Legend Components; Id=137104
  Name=Basic Roof : Generic Roof - 300mm - Filled (Section); Category=Legend Components; Id=137105
  Name=Floor : Generic Floor - 400mm - Filled (Section); Category=Legend Components; Id=137106
  Name=Compound Ceiling : 600 x 1200mm grid (Section); Category=Legend Components; Id=137107
  Name=Compound Ceiling : 600 x 600mm grid (Section); Category=Legend Components; Id=137108
  Name=Compound Ceiling : GWB on Mtl Stud (Section); Category=Legend Components; Id=137109
  Name=Roof Soffit : Generic - 300mm (Section); Category=Legend Components; Id=137110
  Name=Curtain Wall : Exterior Glazing (Floor Plan); Category=Legend Components; Id=137111
  Name=Curtain Wall : Storefront (Floor Plan); Category=Legend Components; Id=137112
  Name=Basic Wall : Exterior - Brick on Mtl. Stud (Floor Plan); Category=Legend Components; Id=137113
  Name=Stacked Wall : Exterior - Brick Over Block w Metal Stud (Floor Plan); Category=Legend Components; Id=137114
  Name=Basic Wall : Exterior - Block on Mtl. Stud (Floor Plan); Category=Legend Components; Id=137115
  Name=Foundation Slab : 150mm Foundation Slab (Section); Category=Legend Components; Id=137116
  Name=; Category=Legend Components; Id=137117
  Name=; Category=Legend Components; Id=137118
  Name=; Category=Legend Components; Id=137119
  Name=; Category=Legend Components; Id=137120
  Name=; Category=Legend Components; Id=137121
  Name=; Category=Legend Components; Id=137122
  Name=; Category=Legend Components; Id=137123
  Name=; Category=Legend Components; Id=137124

These legend components are the keepers of the images displayed in the type preview dialog. The graphical previews are new in 2010 and so the presence of these elements is also new. The exposure of their geometry to the API is not intentional and may be removed again in future. Their only function is to create and hold that one image, and the user has no other way to interact with them.

How can we improve our filter to eliminate these unwanted elements?

Since the legend components have a valid category, we could simply add that additional criterion to the list of properties that we are checking, for instance like this:

const string _CategoryNameLegendComponents
  = "Legend Components";

  if( !(e is Symbol)
    && !(e is FamilyBase)
    && (null != e.Category)
    && (_CategoryNameLegendComponents != e.Category.Name)
    && (null != e.get_Geometry(opt)) )
  {
    // . . .
  }

Instead of using a string comparison on the category name, we could also determine the element id of the legend component category and compare that with each candidate element id.

However, both of these options would add yet another item to an already lengthy list of checks.

A simpler option that seems to work well in the tests I have run so far is to skip checking the object type at all, and replacing it by requiring a valid level, like this:

  if( (null != e.Category)
    && (null != e.Level)
    && (null != e.get_Geometry(opt)) )

Besides being simpler and easier to understand, this check is probably also slightly more efficient. It has not been extensively tested yet, so please let me know if you discover any situations in which it fails.

Here is the current version of the Revit API introduction labs, including the new version of Lab 2-2 to select all model elements using this criterion. The labs are still in the process of being further updated and enhanced for the Revit 2010 API and its new features. All of the labs are provided in two versions, one each for C# and VB.

VB Samples and Other Questions

I have been very quiet now for a few days. The reason is that I went on a climbing weekend to Mallorca with my brother and left my laptop in the car while we went for a climb. The car was broken into, and the laptop and all my valuables were stolen, right down to the bicycle keys. Since I had actually used the bicycle to get to the airport, the first thing I had to do on arriving back was to borrow a saw to break my own bicycle lock. Now I am in the painful process of restoring data to a temporary computer. A valuable lesson in letting go, I suppose. More on this below.

Anyway, here are some queries on different topics, some of which have been touched upon previously, and an updated reiteration may be of general interest:

1. Programmatically triggering IFC export.
2. ImportExport SDK sample in VB.
3. OnStartup sample code in VB.
4. 64 bit OLE DB access.

Question: How can I trigger a daily export of a Revit model to an IFC file?

Answer: I am sorry to say that there is currently no API access to this functionality. One option that you might explore is to simulate the user input required for this repetitive task programmatically. You might do this directly using the Win32 API, or make use of some utilities that provide easier access to this functionality. Here are some of the previous posts dealing with related topics:

• Driving Revit from outside.
• The Revit Window handle and modeless dialogues.
• AutoHotKey.

Another option that may fit your requirements perfectly but is not officially supported is the use of the Revit journal file. Every action performed through the Revit user interface is recorded in a journal file, located in a subfolder of the Revit installation folder. We once discussed how to obtain the path of the current journal file. Journal files can be rerun to reproduce the actions performed in a previous session, for instance by specifying them on the Revit command line during start-up. Custom applications can define what data their commands register in the journal file, and how to process that data when a journal file is replayed, as demonstrated by the Revit SDK Journaling sample. In your case, however, you would possibly not need to do any programming or customisation at all, just start up Revit, perform the IFC export, close down Revit again, and save the resulting journal file. This file might be reusable to automate the IFC export on a daily basis, just as you require.

Question: The Revit SDK 2010 provides a sample application named ImportExport which is of interest to me. Unfortunately, it is in C#, I am only familiar with VB, and the example is quite comprehensive. How can I convert this to VB, please?

Answer: We already discussed the topics of conversion, disassembly, decompilation, Lutz Roeder's Reflector tool and the related topic of obfuscation in previous posts. This tool can be used perfectly well to decompile the Revit SDK Samples, as well. The decompiled code can be displayed in a variety of different languages, including Delphi, managed C++, Chrome and Visual Basic. As said, the ImportExport sample is written in C#. I opened the compiled assembly ImportExport.dll in Reflector and asked to see the source code of the Command class disassembled into Visual Basic. Here is the result:

Public Class Command
  Implements IExternalCommand
  ' Methods
  Public Function Execute( _
    ByVal commandData As ExternalCommandData, _
    ByRef message As String, _
    ByVal elements As ElementSet _
  ) As Result
    Try 
      If (Nothing Is commandData.Application.ActiveDocument) Then
        message = "Active view is null."
        Return Result.Failed
      End If
      Dim mainData As New MainData(commandData)
      Using mainForm As MainForm = New MainForm(mainData)
        If (mainForm.ShowDialog = DialogResult.Cancel) Then
          Return Result.Cancelled
        End If
      End Using
    Catch ex As Exception
      message = ex.ToString
      Return Result.Failed
    End Try
    Return Result.Succeeded
  End Function
End Class

I will leave it up to you to decompile the rest of the classes, if you wish. Alternatively, there are other tools available which decompile an entire application in one go.

Nowadays, Reflector is available from Red Gate.

Question: I would like my application to run automatically every time a file is opened. I assume this can be achieved using the OnStartup method. How is OnStartup used in VB.NET?

Answer: We already looked at this topic once previously, and provided a short description on registering to application events in VB. I repeated the steps described there in the Visual Studio 2008 environment for Revit Architecture 2010, and implemented a simple sample external application named OnStartupVb and implementing OnStartup in Visual Basic for you. The description provided in the previous post for Revit 2009 remains valid for 2010 as well. Here is the resulting source code of the external application class:

Imports Autodesk.Revit

Public Class App
  Implements IExternalApplication

  Public Function OnShutdown(ByVal a As ControlledApplication) _
  As IExternalApplication.Result _
  Implements IExternalApplication.OnShutdown
    Return IExternalApplication.Result.Succeeded
  End Function

  Public Function OnStartup(ByVal a As ControlledApplication) _
  As IExternalApplication.Result _
  Implements IExternalApplication.OnStartup
    System.Windows.Forms.MessageBox.Show( _
      "OnStartup says Hello from Jeremy", _
      "OnStartup VB")
  End Function

End Class

Here is a copy of the full Visual Studio solution OnStartupVb.

Question: No OLEDB provider registered ... How can I retrieve a record set from an Access 2007 database using VB.NET in 64-bit Vista?

Answer: If you install 32-bit Revit 2009 in 64-bit Vista, then this is possible. This requires compiling your Revit plug-in in a 32-bit OS, then loading it into 32-bit Revit in the 64-bit OS. On the other hand, if the Revit version is 64-bit, one possible approach is to use the SQL server database accessing driver. Note that the 32-bit version of Revit 2010 cannot be installed on a 64-bit OS, so in that case using SQL Server or SQL Server Express would be the recommended option.

Thanks to Joe Ye for this answer!

Back to the topic of Mallorca. Apart from criminality, it is a surprisingly beautiful place with large areas of untouched nature, mountains, and almost inaccessible beaches, in spite of the strong touristic focus in the cities and villages. Also a huge amount of beautiful climbing opportunities. Here I am walking along a path heading for both a lonesome beach and a challenging cliff:

The weather was hot enough to require some protection against the sun:

Converting between VB and C#, and .NET Decompilation

Here is post to follow up on the comment on converting between C# and VB code by Rod Howarth on the post on Application Events in VB.

First of all, converting code between C# and VB is possible and can be done automatically. C# and VB.NET both produce the identical intermediate language IL code, which is what is actually stored in the .NET assembly and evaluated by the .NET framework. The IL code contains all information required to regenerate the source code. So, on one hand, you can translate between C# and VB. Furthermore, you can even recreate source code in any language of your choice by decompiling the IL code in the assembly.

To translate between C# and VB, just google for "c# vb translator". Rod mentioned a couple of such translators; he says:

Also useful for anyone who is a VB coder and wants to convert samples are the many VB to C# code converters available. Using a Google query such as this one will turn up tools such as http://www.developerfusion.com/tools/convert/csharp-to-vb and http://www.carlosag.net/Tools/CodeTranslator. They may not do whole projects but they can help you decipher the samples!

To analyse or decompile any .NET assembly, even without access to the source code, a tool that I use is Reflector by Lutz Roeder.

It includes reverse engineering functionality, for instance a decompilation and source code generation feature, so it can read your compiled DLL and decompile the IL intermediate language it contains into various languages including C#, VB, managed C++, and others. It can obviously also be used to list all namespaces and classes defined in an assembly, and their methods and properties.

Here is an example of decompiling a Revit external command assembly I built using C# and requesting VB code for it:

See the VB code? I wrote this application in C#! My version of Reflector will also decompile into Delphi, Chrome and managed C++, besides C# and VB.

Although ... please note that even Reflector is not always 100% correct ... if you look carefully at the screen snapshot, note that it seems to have come up with something strange; in the line following

If (Not Nothing Is PlanarFace) Then

it says

Dim <>8__locals2 As <>c__DisplayClass1

That will probably not compile correctly. Thanks to Adam Nagy, a DevTech colleague of mine, for noticing this error.

I find this an invaluable tool, and often use it to explore my own .NET assemblies, just to ensure that they really do contain what I am expecting them to.