To process failures correctly, it is necessary to hook up to the actual failures processing mechanism. Therefore, conclusions cannot be drawn about the state of failures to be processed when Transaction.Commit() is called. These checks and changes may make some failures disappear or, more likely, can post new failures. Auto-join, overlap checks, group checks and workset editability checks are just to name a few. It is important to remember there are many things happening between the call to Transaction.Commit() and the actual processing of failures. Although the first two methods for handling failures should be sufficient in most cases, this last option can be used in special cases, such as to provide a better failure processing UI or when an application is used as a front-end on top of Revit.

For all possible errors using the FailuresProcessing event.įinally, the API offers the ability to completely replace the standard failure processing user interface using the interface IFailuresProcessor.

For a given transaction using the interface IFailuresPreprocessor.

If an operation (or set of operations) on the document requires some special treatment from a Revit add-in for certain errors, failure handling can be customized to carry out this resolution.

The user is presented information and options to deal with the failures. Normally posted failures are processed by Revit's standard failure resolution UI at the end of a transaction (specifically when Transaction.Commit() or Transaction.Rollback() are invoked).

Network failure autodesk revit student