MainMenu() Close item does NOT call function defined in SetCloseIntercept #2355
Comments
|
I have updated to fyne version - fyne.io/fyne/v2 v2.0.3 and the problem still exists. |
|
I can confirm the |
|
For added info it seems that the macOS hard-coded quit item does work as expected, so it's just the Fyne window menus that need fixed. |
|
Hi. Thanks for the quick response. I was running under Linux. I actually didn't try Windows!I was still getting the exception with v2 of fyne.Is it possible to make the 'Quit' option configurable or optional. I saw a blog where some guy wanted to change the name. I noticed that I got the exception when I did a close from any menu item. I am not sure if the exception was the same. I will check.I'm away for a couple of days. I will investigate more when I get home.Keep up the great work 😃Stuart
|
|
We can't make Quit optional and have real cross-platfom parity because Quit is mandatory on macOS. |
|
Hi. I just noticed that with the code below: The dialog is shown in a modal window as expected, however if I close using X (close window button) the shouldClose method is called recursively! I can press X many times while the dialog is visible, each time the background gets darker and a new dialog is shown. For each press 'Yes' I am returned to the previous dialog. Am I doing something silly or is this unexpected behaviour. I have overcome at the moment by having a global lock value to prevent the recursion but this is ugly. Also I cannot get the exception messages to show in the logs. I will keep an eye in it :-) window.SetCloseIntercept(shouldClose)
...
func shouldClose() {
if dataHasChanged() {
d := dialog.NewConfirm("Save Changes", "There are unsaved changes\nDo you want to save them before closing?", saveChangesConfirm, window)
d.Show()
} else {
window.Close()
}
}
func saveChangesConfirm(option bool) {
if !option {
fmt.Println("Quit without saving changes")
window.Close()
}
} |
Every time the user tries to close the window it is running your callback - and displaying a new dialog. I don't think the toolkit can do this, as we have no idea what your close intercept handler will do. Also my guess is that some recursive calling may be due to your code, not certain as the link to I think that the main problem of this ticket will be resolved by us landing #2356 |
|
Fixed the underlying problem on |
The Main Menu automagically adds a 'Quit' item. This closes the application.
The SetCloseIntercept method allows a function to be defined that is called before the window closes and if not appropriate the application close can be aborted. This allows the user to save any unsaved data or perform any actions that are required for the proper closing of the application.
I have set a Close Intercept function but it is NOT called when the Quit menu is clicked!
If I click the X (Top right on windows and most Linux Window managers) to close the application the Close Intercept function IS called and the behaviour is as expected.
I would expect the behaviour to be the same for both!
Because of the way the Quit menu is added I cannot alter this behaviour. I have used a work around but it throws exceptions to the console when I close the window via the quit menu.
Note that if I w.Close() from any where outside the main thread I get exceptions. For example if I add another menu item and add an action that calls w.Close(), the application closes but I get loads of exceptions in the console. What is the proper way to close the application from an event thread?
To Reproduce:
Steps to reproduce the behaviour:
Example code:
Device (please complete the following information):
My workaround code:
However when invoked the following is sent to the console
The text was updated successfully, but these errors were encountered: