|
|
|
With regen control,
dynamic model updating, journalling, error handling all in integration
context, the Revit Engg team is trying to integrate your external commands
and applications as closely as possible with Revit so that it feels like part
of native Revit. With the new Failure API, API users will now be able to –
|
|
•define and post failures from within API code when a
user-visible problem has occurred.
|
|
•respond to failures posted by Revit and by API code through
code in your application.
|
|
|
|
Failure Posting: If
you are using the failure posting mechanism to report your problem, all you
need to do is:
|
|
•If you are creating a new failure not already existing in
Revit, define the new failure and register it in the
FailureDefinitionRegistry during the OnStartup() call of your
ExternalApplication (new failures must be registered at Revit startup)
|
|
•Find the failure definition id, either from the
BuiltInFailures classes or from your pre-registered custom failure using the
class related to FailureDefinition
|
|
•Post a failure to a document that has a problem - using the
classes related to FailureMessage to set options and details related to the
failure
|
|
|
|
Failure Handling:
Normally posted failures are processed by Revit's standard failure resolution
UI at the end of transaction. The user is presented information and options
in the UI to deal with the failures.
|
|
However, if your
operation (or set of operations) on the document requires some special
treatment for certain errors (or even all possible errors), you can customize
failure resolution. Custom failure resolution can be supplied:
|
|
•For a given transaction using the interface
IFailuresPreprocessor.
|
|
•For all possible errors using the FailuresProcessing event.
|
|
Finally, the API
offers the ability to completely replace the standard failure processing user
interface using the interface IFailuresProcessor.
|
|
|