BindToClose doesn’t seem to do anything. It runs the callback, but it does not prevent the window from being closed.
Also, PluginGuiService is not visible in the explorer anymore (next gen explorer and current Qt explorer.)
@CycloneUprising since you posted the announcement thread on this back in 2018, I figured I’d tag you. Not sure if you’re still the right contact, but maybe you can pass it on. Thanks!
Expected behavior
Having something bound with BindToClose() should prevent the window from being closed if I press the X to close the window.
Additionally, enabling the setting “Show Plugin GUI Service in Explorer” should, you know, show that service. It no longer does.
Both of these are pretty important features for plugin development.
The documentation is out of date for BindToClose, we’ll get that updated. This was an intentional choice put in a while back. We don’t want plugins to block the closure of a widget, but merely act on user intent.
Thanks for getting back to me. I’m not sure I necessarily agree with the decision but I can see why it was made.
What is the suggested solution for when you need to ask the user to save or discard changes made while using a widget? For now, I’m just re-enabling the widget, which seems like it’s side-stepping that whole decision to make BindToClose not close the widget.
If the intent is to limit nefarious/annoying plugins, perhaps it would be better to implement this case specifically. Maybe add a boolean property to DockWidgetPluginGui called UserModifiedState or similar - then Studio can do the popup saying, “You have changes, are you sure? [Discard] [Cancel] [Don’t ask again for this widget].” Studio can enforce a timeout for when the plugin can set UserModifiedState again after the user attempts to close the window.
Basically, just like you can do with a website, where your browser asks if you really want to navigate away. I found some sample JS for that:
window.addEventListener('beforeunload', function(event) {
// The preventDefault() method cancels the event if it is cancelable,
// meaning that the default action that belongs to the event will not occur.
event.preventDefault();
// Chrome requires returnValue to be set.
event.returnValue = '';
return '';
});
While you’re here, could you also have someone check into the behavior when a floating DockWidgetPluginGui is closed? Right now, it seems like it always sends the main container back to the game viewport, but that’s not what I want it to do. I have a main widget that opens other widgets, and when I close them I want to keep the main widget in focus.
In other words, closing a floating widget should not change what the main dock container is showing.
I can file a separate bug report for this if that’s helpful.
