There’s no event for it, but any JS you include using craft()->templates->includeJs() from your field type's getSettingsHtml() method will get fired each time a new Matrix sub-field is created, so if you code your field type correctly with properly namespaced inputs] IDs/names, no event will be needed.
The thing about Matrix is, there’s no way to predict what the actual input IDs/names are going to be when they are added to the DOM, as they will be run through TemplatesService::namespaceInputs() with the namespace blockTypes[__BLOCK_TYPE__][fields][__FIELD__][typesettings]
, and those “__BLOCK_TYPE__” and “__FIELD__” placeholders are replaced dynamically by MatrixConfigurator’s Javascript before adding the settings HTML to the DOM.
Regular field settings get namespaced too, but in a more predictable way (their namespace will always be types[FieldTypeClassHandle]
), so it can be tempting to just hard-code the namespaced IDs directly into your Javascript, like this:
$js = "\$('#types-FieldTypeClassHandle-myInputId')" // ...
Matrix’s unpredictability shows why it’s important to not do that, and instead always use TemplatesService::namespaceInputId() and namespaceInputName() whenever you need to reference an input’s ID or name from your Javascript:
$namespacedId = craft()->templates->namespaceInputId('myInputId');
$js = "\$('#{$namespacedId}')" // ...
When you let TemplatesService generate the namespaced IDs/names for you, you can be sure that it will always give you an ID/name that will match whatever the actual ID/name will be in the DOM.