Announcing PluginGui:BindToClose

[CycloneUprising]

Overview

As of the latest release, we support PluginGui:BindToClose.

This allows your plugin to intercept & custom-handle user requests to close a PluginGui (e.g. when they click on the little ‘x’ in the corner of a dock widget hosting a plugin gui).

This allows you a sanity check before the user closes the GUI for your plugin, say to double-check that they really want to do this, or to give them a chance to save work.

Example

A fairly frivolous example:

local counter = 0
print ("001 pluginGui.Enabled = ", pluginGui.Enabled)
pluginGui:BindToClose(function()
  print ("002 pluginGui.Enabled = ", pluginGui.Enabled)
  counter = counter + 1
  print ("Counter == ", counter)
  if (counter > 3) then
    print ("003 pluginGui.Enabled = ", pluginGui.Enabled)
    pluginGui.Enabled = false
    print ("004 pluginGui.Enabled = ", pluginGui.Enabled)
  end
end)

Assuming pluginGui is already set to some PluginGui, this call would mean the user has to click on the ‘x’ 4 times to get the PluginGui to actually close.

Caveats

This is not like the BindToClose on the DataModel (https://www.robloxdev.com/api-reference/function/DataModel/BindToClose), where the bound-to "Close" will happen once the callback completes.

Here, once you set a callback function like this, the plugin gui will not close on its own without an explicitly setting pluginGui.Enabled = false.

Flavor Text

Oh snap... I don't have anything prepared... THINK, Banks, THINK!!!! Um... Family Circus, sure, kids love that, right?
"Pizgetti!!!
Whew... close one...

[colbert2677 (ImagineerColbert)]

So essentially, by using this function, you have control over when the Gui closes or not. Good for confirmation and dialogues and uh… preventing people from closing your plugins… like some old ones I know.

Good update I suppose.

[ChipioIndustries (chipio)]

This’ll clear up a few headaches. Thanks!

[Stormcell]

Nice to see you’re working on Plugins, does that mean we’ll get a fix for the Plugin.Deactivated event’s bug? It fires both when the plugin is deactivated, and also when the plugin is activated which of course can cause some major headaches, espeically for the first time people are learning to create plugins (I speak from experience on that one). At the very least could the documention for this event be changed to notify people of the issue? This was reported almost 3 years ago in this thread, but nothing ever came of it.

[CycloneUprising]

@Stormcell
I think that should be fixed. I have vague memory of dealing with the mess around plugin activation. Can you confirm?

[Stormcell]

Here you go. Run that as a plugin and it’ll create a button for it in the toolbar you can use to test the issue. It’ll tell you what value plugin:Activate() was given when you pressed it and when plugin.Deactivation fired in output. Tried to make it as user-friendly as possible.

DeactivationBugPluginTest.rbxmx (2.0 KB)

[CycloneUprising]

@Stormcell
Thanks, I have opened a bug report and will look into it. can’t promise how soon but will try to get to it ASAP.