Registration, binding, and cleanup

Understand when the framework becomes available, when to open the interface, and how to release resources when disabling the add-on.

Responsibilities of the four stages

Step	Purpose	Common misunderstanding
Register	Join framework service coordination	Importing is not registration.
Bind	Obtain this add-on's client handle and root	Binding does not open a window.
Open	Display the declared page in a valid editor region	Page and size declarations do not open windows.
Release and unregister	Clean up the client, then leave coordination	Closing one window does not dispose the whole add-on.

Enable and disable order

The template binds on demand. Enabling registers the framework and entries; first use binds and registers actions. Buttons reuse one handle instead of creating clients on every click.

Lifecycle sequence

Plain text

Enable: register framework → register operators/panels
First action: bind client → register actions/state → open window
Continue: reuse handles and stable keys
Disable: remove entries/callbacks → release clients → unregister framework

The complete copyable implementation is in Complete first-add-on source. Merge into existing registration functions rather than creating two unaware entry systems.

Creators own cleanup

Remove your registered menus, shortcuts, timers, handlers, and business subscriptions.
Client dispose releases its windows and bridge resources, not your application cleanup.
Release unused state/event subscriptions. Route changes must not leave duplicate listeners.
Dispose the SDK only when the whole page no longer needs it, not when one component closes.

Embedded copies, shared runtime service

Each add-on retains its own copy and identity. Coordination selects the service owner. Do not rely on enable order, alphabetical names, or other add-ons' internal resources.

Use different client_key values only for genuinely independent clients. Ordinary single-window tools can use the default. See Window position, size, and visibility.

Why restart after disk updates?

Replacing files does not replace loaded services. Hot replacement is unsupported. Save and restart Blender when prompted. Identity conflicts require source verification, not repeated window toggling.

Disabling and restarting should leave no duplicate entries. That real result differs from inspecting source order. See Framework updates and add-on coexistence.

Based on the template, public entry points, and runtime documentation.

Back to User guide · All topics