Revit API could benefit greatly if we had TextElement event hooks such as:
- OnBeginEditingModeEvent when a text element enters into an editable state.
- OnEndEditingModeEvent when the text element is clicked out of, triggered just prior to the DocumentChanged event, allowing changes to be processed before they are committed as changes to the Document.
- OnKeyPressEvent for features like autocomplete or string parsing operations.
- OnResizeEvent for bounding box geometry changes, which would allow precise positioning of text elements.
- OnTextRangeSelectionChangedEvent when a substring is selected for editing.
By convention, it is also helpful to see events begin with "On..." which nicely groups all events in intellisense. I hope going forward, the Revit API team follows this common convention.
I have made an add-in that allows me to dynamically link text inline to data using special syntax, but due to limitations with the API, I cannot fully implement this feature as it requires logic to execute when the text element enters editing mode. The first two events listed are vital in the implementation of these features. Currently I am relegated to using Idling events and checking for selection changes every n milliseconds, then preemptively conducting my modifications across the selection set in case the selection becomes edited, and then reverting back if the selection is canceled. This is needless expense and computation if I just had a hook to an OnEdit event.
More broadly, it seems the API's most unrealized opportunity is from disaggregated events across the spectrum of the API's Elements. There are no Element events and no UI events (mouse events, key events, etc.) targeting the model and elements at all. All events are application and document-level events. The opportunity for developers is quite large if we have access to events at the Element level, and access to the user's interaction with those Elements.
