Revit Adapter details

As already mentioned, the adapter is divided in two sides. On the code level this means the adapter instructions are being processed by two objects:

• BHoM side - RevitAdapter
• Revit side - RevitUIAdapter

In most cases the above objects exist on two separate threads, one per each side. This means the data needs to be exchanged between the threads, which is done with the use of Sockets and data package dispatchers:

• BHoM side - RevitAdapter
• Revit side - RevitListener

In general case, the adapter action procedure can be explained as follows: once RevitAdapter receives an adapter instruction, it passes it to RevitListener via Sockets, locks itself to wait, while RevitListener raises an event that triggers CRUD methods in RevitUIAdapter. Then, once CRUD methods return output, it is passed to RevitListener, which sends in back to RevitAdapter - it then unlocks itself and returns the output to the user.

In a case when the UI runs on Revit thread (Dynamo or a custom Revit app), data exchange between the threads is not needed. Instead, an instance of RevitUIAdapter is assigned to RevitAdapter.InternalAdapter static property and CRUD methods get triggered directly based on instructions received by the RevitAdapter.

Both scenarios are presented in the flowchart below. Flowchart explaining each of the adapter actions can be found in Pull/Push/Remove detail sections.