|
|
|
The new event
Application.DocumentChanged is raised after every transaction gets committed,
undone, or redone. This is a readonly event, designed to allow you to keep
external data in synch with the state of the Revit database. To update the
Revit database in response to changes in elements, use the Dynamic Model
Update framework.
|
|
|
|
The event handler
receives a DocumentChangedEventArgs instance as an input argument which
provides information on the operation performed and the document and elements
involved. Some of its most important properties and methods are therefore the
following:
|
|
Operation: the
operation associated with this event.
|
|
GetDocument: the
document associated with this event.
|
|
GetAddedElementIds:
the set of elements newly added to the document.
|
|
GetDeletedElementIds:
the set of elements that were deleted.
|
|
GetModifiedElementIds:
the set of elements that were modified.
|
|
GetTransactionNames:
the names of the transactions associated with this event.
|
|
|
|
The new event
UIApplication.Idling is raised when it
is safe for the API application to access the active document between user
interactions. This event is raised only when the Revit UI is in a state where
the user could successfully click on an API command button.
|
|
Handlers of this
event are permitted to make modifications to any document (including the
active document), except for documents that are currently in read-only mode.
|
|
In order to change
a document, users must begin a new transaction for that document. This
transaction will appear in the Revit undo stack and may be undone by the
Revit user.
|
|
Because this event
is invoked between user actions in the Revit UI, if the handler for this
event requires a significant amount of processing time, users will perceive a
slowdown in the responsiveness of Revit. If the execution for updates can be
safely split across multiple calls to this event, the user perception of
Revit responsiveness will be improved.
|
|
|