<ruleName>_allowModify? Event occurs prior to the modification of a dynamic rule. The handler is a Boolean method that specifies whether the modification is to be allowed or not. If it returns True, then the modification proceeds. If it returns False, then the modification is cancelled.
<ruleName>_allowDelete? Event occurs prior to the deletion of a dynamic or modifiable rule. The handler is a Boolean method that specifies whether the deletion is to be allowed or not. If it returns True, then the deletion proceeds. If it returns False, then the deletion is cancelled.
<ruleName>_preDelete Event that happens just prior to the deletion. If the rule was a Child rule, this event happens prior to the 'deleteSelf' events. The handler can see the current value of <ruleName>. The handler is a method that returns a list of actions to be performed.
<ruleName>_postDelete Event that happens just after the deletion. If the rule was a Child rule, this event happens after all of the 'deleteSelf' events. The handler can not access the value of <ruleName>, unless the deletion exposes an underlying 'default' design-rule. The handler is a method that returns a list of actions to be performed.
The following events and their handlers are used to indicate when dynamic parts are added and deleted. These handlers are normally coded as "design rules" in the design of the part that is being added or deleted.
preCreateSelf Event happens just after the part is created. Obviously the part has to be created in order for its event-handler to run! The handler is a method that returns a list of actions to be performed.
allowDeleteSelf? The handler is a Boolean method. If it returns False, then the child is not deleted, nor are any of the modifications underneath, if any. If the deletion is disallowed, no error or other notification happens to the caller — it appears to the caller as if the deletion succeeded, but in fact the part is still there.
preDeleteSelf Event happens just before the child-rule is deleted, and prior to the deletion of any dynamic/modified rules underneath the child. The handler is a method that returns a list of actions to be performed.
postDeleteSelf Event happens after all dynamic/modified rules underneath this child have been deleted, and just before the rule is deleted. So the child is still there, but stripped of all lower level dynamic rules. The handler is a method that returns a list of actions to be performed.
All the actions in the action-list take place within the same undo-group as the original triggering event, including any actions invoked by cascading events. This implies that if the user “undoes” the original operation, all the event-handler-controlled changes will also be undone, in order to bring the model back to the original state. Events are not triggered when the operations happen as part of undo-ing or redo-ing.
Errors that occur during the evaluation (creation) of the action-list, or during the processing of the action list (‘part’ is not a Part, name of rule is not a Name, etc.) are silently swallowed. This makes them very difficult to debug! Work on your event-handler rules slowly and carefully to be sure that they’re really right.