You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
For the moment the only way to respond to the lifecycle events of the webview component are the standard connectedCallback and disconnectedCallback for Web Components.
These callbacks are triggered outside the control of Cmajor. They rely on the underlying webview engine, and they cannot be used reliably since there are many factors that may trigger ot not them. In particular, from my tests, the disconnectedCallback is never triggered when the plugins'UI is hidden inside a VST/CLAP host, or when the plugin is removed.
There are cases where having control on the UI being closed or hidden is critical. Cleanup routines, like removing patch listeneres, or stored status saving.
A more reliable solution would be if Cmajor provided dedicated callbacks, connected to the plugin's editor lifecycle.
The text was updated successfully, but these errors were encountered:
For the moment the only way to respond to the lifecycle events of the webview component are the standard
connectedCallback
anddisconnectedCallback
for Web Components.These callbacks are triggered outside the control of Cmajor. They rely on the underlying webview engine, and they cannot be used reliably since there are many factors that may trigger ot not them. In particular, from my tests, the
disconnectedCallback
is never triggered when the plugins'UI is hidden inside a VST/CLAP host, or when the plugin is removed.There are cases where having control on the UI being closed or hidden is critical. Cleanup routines, like removing patch listeneres, or stored status saving.
A more reliable solution would be if Cmajor provided dedicated callbacks, connected to the plugin's editor lifecycle.
The text was updated successfully, but these errors were encountered: