PluginToolbarButton:Destroy() does NOT remove itself from Toolbar

Trying to :Destroy() a PluginToolbarButton does absolutely nothing

I should note that PluginToolbar:Destroy() also does nothing.

Use case:

  • creating disposable PluginToolbarButtons and PluginToolbar
    (showing buttons and are useless at the time is terrible UX)

I’m aware of DockWidgetPluginGui however this is easier to use and some prefer to keep their viewport clean.


local toolbar = plugin:CreateToolbar("Toolbar")
local Button = toolbar:CreateButton("Button","","")
	Button.Parent = nil

plugin.lua (190 Bytes)



Not sure if related but a while ago some (not all of them) plugins started to glitch when I try to disable them their Toolbar Buttons wont go away. And they also wont work anymore because the plugin is disabled.

1 Like

Thanks for the report! We’ve filed this internally and we’ll follow up here when we have an update for you.


I am in the process of checking over bug reports and following up on some bugs that haven’t received any activity in a while.
Is this issue still occurring or can you confirm that this bug has been resolved?

Yes, I can confirm that this still happens

I’m having this issue currently.

1 Like

Thanks for the info. As soon as there is an update i will pass it on.


This bug still exists and I would make a new topic if I could… But, I can’t.

attempting to call the Destroy method on a PluginToolBar or a PluginToolBarButton

  • The bug is simple, attempting to call the Destroy method on a PluginToolBar or a PluginToolBarButton, it will not destroy it as expected.

  • The bug happens in plugins.

  • No idea when it has happened, but it has been reported before. Making a new post because the post has been inactive for a long while.

  • Screenshots:
    Screen Shot 2021-07-27 at 12.08.14 AM

  • Method of reproduction (can be found in screenshot):
    – Using a plugin, create a toolbar and a button with it.
    – Attempt to call destroy on those instances.

  • Reproduction is 100%.

1 Like

I’m also having issues with this right now.

This continues to be an annoying problem. As someone who is developing plugins as part of a suite, I would rather be able to group them all together under a single toolbar than have separate toolbars with only a single action which simply toggles the pseudo-enabled/disabled state of the said plugin. Currently, I am left with the following if I try to add a button to the bar, then fully deactivate and reactivate a plugin.


Honestly, the whole RibbonBar API needs to be redone. Qt Ribbons has tons more features that just buttons.

Where are…

  • Dropdowns
  • Small Buttons
  • Text Boxes
  • Checkboxes
  • Radio Buttons
    …just to name a few

To the OP: Its likely Qt hasn’t be told to react to the instance being destroyed from code


I am still not able to destroy toolbars.


Iterating on plugin code using Accessible Plugins is made extremely difficult due to the fact that the plugin is not able to properly clean itself up when it is disabled. It shocks me that this has been an issue for almost two years and nothing has been done to fix it. @MisterGreenTurtle


This is frustrating. I was really trying to implement customizable toolbars for my plugin, but it is currently not possible due to this limition.

1 Like

Yesterday marked the 2-year aniversary for this bug (happy birthday). This is still a recurring issue and I was able to reproduce the bug since a minute ago. The ToolbarButton should remove itself from the Toolbar when calling PluginToolbarButton:Destroy(), but it did not.

Are there any updates regarding this?

1 Like

Pretty sure this is not a bug and in fact a missing feature. You may want to file a feature request instead so it is handled appropriately internally.

If you want a solution you can use my createSharedToolbar module which is what all my GeomTools plugins use to group themselves into one toolbar and work even if you dynamically load / unload them by dynamically binding the different Lua code to same button (which continues to exist), and recreating that button if it gets destroyed by the owning plugin unloading.


Still an issue over 2 years after the original topic was posted.
Thanks for sharing this solution! You’re awesome!

1 Like

Still an issue almost 3 years later. I feel like out of every bug report, this would be the easiest to fix/implement. :confused:


It is still not working,
:Destroy() does nothing on toolbarbuttons