If you read that post immediately after it was first published, I suggest you go back and have a quick look again now, since I revisited it and added a significant chunk of information after the initial publication.

Now I would like to delve deeper into the detailed API aspects.

Before proceeding with that, let me mention two other good bits of news:

Trillions – Thriving in the Emerging Information Technology

This is the first pure technology related book I have read all the way through in ages, and I am very enthused.
It was distributed to all participants of the internal Autodesk Tech Summit in Boston and discusses design and technology for pervasive computing.

It provides numerous shockingly obvious and often quite old insights, a very critical view of our current use of Internet and so-called cloud technologies, and an inspiring and thrilling read.

The topic is how to harness and live in – as opposed to 'with' – the unbounded complexity of the trillion-node network of connected devices that we are inevitable heading towards, and will lead to catastrophe unless we radically change some fundamental aspects of the ways we handle and share information.

I highly recommend reading this book.

I highly recommend abstaining from all use of the word 'cloud computing' until you have completed it :-)

Visual Studio 2013 Supports 64 Bit Edit and Continue

Visual Studio 2013 and the CLR 4.5.1 now support 64-bit Edit and Continue when debugging C# and VB applications.
Stephen Preston is happy about that.

You have three votes, and you can apply them all to this one wish, if you like.

Family API Add-in

Getting back to the Revit API and programmatic work with families in particular:

As I pointed out, Steve's presentation covers key family editor concepts from a user point of view.
From a programming point of view, there are two main family related areas to consider:

Creation of a family, i.e. working in the context of family document.

Use of a family, mostly in the context of project document.

Since a family instance can also be inserted into a family document to create a nested family structure, the second point is actually relevant both in the family and project context.
It includes tasks such as loading a family, placing instances, manipulating types and existing instances.

Both of these aspects represent large important topics that have been frequently discussed here in the past.

Before Revit 2010, only the second area was covered by the API.
Programmatic creation of families and the entire use of the API in the family context was impossible before the introduction of the
Family API.

The basic steps to programmatically create a family from scratch are demonstrated in detail in section 3, Revit Family API, of the
ADN Revit API training material.

The programmatic
creation and insertion of an extrusion family provides
a more recent and simplified example of defining and loading a family and placing an instance without exploring the more complex and interesting aspects of the definition such as setting alignments and adding types.

The
family API topics concluding
the preceding post list the programming concepts that Steve and I decided to revisit:

Load family and place instances

Pick interaction and modify instances

Instance and symbol retrieval, nested type modification

It also provides a full snapshot of the source code and Visual Studio solution implementing the three external commands implementing these concepts and an external application wrapper defining a nice compact user interface to access and launch them:

CmdTableLoadPlace

CmdTableNewTypeModify

CmdKitchenUpdate

Here is the list of topics to explain their implementation and functionality in full detail:

Checking Whether a Family is Loaded

Before we can start placing any family instances, we need to load our family definition.

Loading it into the project will cause an error if it is already present beforehand, so we need to check for its prior existence before attempting.

All retrieval of database elements is performed using filtered element collectors.
Effective element filtering requires application of as many filters as possible to limit the number of elements retrieved.

Of these, the quick filters are highly preferred, since they enable filtering of elements without loading the entire element information into memory.
Slow filters are also effective, since they enable checking of element properties inside the Revit memory space before the element information is marshalled and transferred out into the .NET universe.
The slowest filtering is achieved by post-processing the element data in .NET after extracting it from Revit.

Assuming that we do not have a terribly large number of families loaded in the project, we can get by in this case by looking at all the families and applying a .NET post-processing step filtering for the desired family name, e.g. using a language integrated
LINQ
query and the generic FirstOrDefault method like this:

Find a Database Element by Type and Name

We check whether the family is already loaded by retrieving all element by filtering of a specific class, also known as .NET type, in this case the Family class, and then post-processing the results looking for a given target name.

This functionality is useful for many different kinds of searches, which led to us already discussing a helper function implementing it, as well as
possible optimisations to it.

In this add-in, for the same of simplicity, I implement it like this without any further attempts at optimisation:

I added a check to ensure that the family definition file is available in the expected location.

Loading the family modifies the database, so a transaction is required.

If you only need a few symbols (also known as types) from a large family, you can load them more effectively one by one by using LoadFamilySymbol instead of loading them all at once through the single call to LoadFamily.

Accessing the Newly Placed Instances

Theoretically, this method could return a list of the instance element ids.
Lacking that, we can find out for ourselves by temporarily registering to the DocumentChanged event before the call, unregistering immediately afterwards, and making a note of all element ids added in between.

Here is the OnDocumentChanged event handler and the element id container I use for that:

As said, the detailed description of the other two commands will follow soon, and the complete Visual Studio solution is available from the overview of the
family API topics concluding
the preceding post.