Here are two little items of general long-standing interest that just came up in a Revit API discussion forum:
These two issues sometimes come as a surprise to developers experienced in OOP and other CAD system programming.
However, there are good reasons for both.
Here are the detailed explanations:
Question: I would like to extend some classes provided by the Revit API, e.g. by inheriting from them and implementing my own derived classes. I think it would be very useful to specialise some classes, like FamilyInstance.
Answer: Do you have any particular goals behind inheriting from FamilyInstance? What would you like to be able to accomplish that inheritance or extensibility would allow?
Question: I created an add-in that uses a Revit family to delimitate an area. I call it a 'marker' and can identify it by its symbol. It helps identify where and how other element need to be placed.
Having a public constructor will allow us to inherit our marker class from FamilyInstance. In fact, a marker IS a family instance, with just some other properties. Now we have to copy some data from the FamilyInstance to the marker it belongs to, like its unique id, location, rotation and so on.
It would be easier for us to serialize and deserialize the class being sure correct data is copied to the database.
Also the code understandability would be improved, since calling new FamilyInstance(x,y,z, rotation, symbol) is much more obvious than calling a static constructor.
Any programmer would expect that calling a constructor such as this would drop a new instance into the project.
Answer: Thank you for the clarification.
The structure of Revit and it’s API is a little bit different than I think you expect, so this is not going to work as well as you hope.
Revit API objects are managed wrappers around native C++ objects used by Revit’s UI and database. Therefore, a FamilyInstance in the API does not actually contain the properties you see – the API code accesses them through the matching native object’s members. So extending our managed classes would not actually allow for new data to end up in the Revit file during serialization – we don’t know how to get the data from your inherited class.
We don’t supply public constructors for many of these objects for precisely this reason – much more needs to happen than just building the object and populating the x, y, z, etc. – the document tables need updating, dependent elements must be added, relationships established etc. So this is what we have methods like NewFamilyInstance and, for our newer element creation calls, static creation methods taking the document and necessary parameters.
If you want to get additional serialized data onto a Revit element, you should look at Extensible Storage in the Revit API.
If you want to make code easier to write and want to 'add' additional members to our classes (so you could have a call to a FamilyInstance.GetMarker method or something like that), you can look at C# extension methods – however, adding such methods will not allow additional data to be stored in those classes unless you implement these members using Extensible Storage.
Question: Looking at the Revit API documentation, I do not see any mention of strong naming.
Is there a particular reason for that?
This can cause several security issues, and some customers may require us to sign our Revit add-in assemblies, which we currently cannot do.
Answer: Yes, this is true. There are good reasons for this.
Here is an explanation why you cannot sign your AutoCAD .NET plug-in with a strong name.
It covers all the technical details and includes some workarounds, which all apply to Revit add-ins as well.
Note that Microsoft modified the strong name verification system so that some security measures related to signatures are now bypassed by default.
I hope these explanations make sense.
There are quite a few surprises lurking in the Revit API and the entire Revit product paradigm for unwary developers experienced in other less parametric and BIM oriented CAD systems, as we have already repeatedly seen in the past:
In fact, as I often point out, one of the hardest tasks for a budding Revit add-in developer experienced in ObjectARX or other CAD system programming is to forget her accumulated previous experience and open her mind for something completely new and different.
Learning something new and letting go of something old can prove very challenging indeed.
And very rewarding.
Good luck!