The question is quite simple. How do I close a ShowSaveFileDialog?
There is apparently no way to close it.
It just keeps hanging around, I guess, until the method closes.
Just exit the window
Are you saying that the window will not close?
That’s a macOS “feature” since High Sierra. You need to do the dialog first and then call the function with a delegate after the dialog was closed. You know: spaghetti code everywhere!
That’s a feature of how Cocoa manages memory.
Just continue with the app and ignore it.
Yes this is a Mac. MacBook Pro 2012 without Mojave.
Thanks for confirming the feature. Annoying.
The problem shows up as a problem when I try to debug the method.
If I put a breakpoint, it hits the breakpoint and hangs so deeply I have to use ForceQuit.
Could put it in a method and solve the hanging problem? I’ll try that.
Have a look at https://forum.xojo.com/48567-closing-the-getopenfolderitem-on-a-mac/0 . And yes, in the IDE is especially annoying.
Thank you Beatrix. This is a simple introduction to delegates (I hope)
I’m looking for a way to choose the dialog. I assume I’d have to have different constructors.
Can I use the parameterList of the Delegate to create a switch to switch for various dialogs?
(Yes I have created a set of constructors)
I’m asking because no one in the forum has used the term, nor does it show in XDev,
and because I make beginners mistakes.
You should be able do that. I made to different classes.
The things I’m seeing suggests
- it needs to go out of scope
- the os needs a chance to update
so something like
Dim f As folderitem
If True Then
Dim dlg As New SaveFileDialog
f = dlg.ShowModal
End If
app.doevents(5) // this _could_ be lower as I have used it with 1 as the param but BEWARE of do events
Breakseems to do the trick
But put a #if debug build around as it should only be a problem in debugger.
a) No, that’s not only a problem in the debugger.
b) No, don’t use DoEvents.
[quote=483374:@Beatrix Willius]
a) No, that’s not only a problem in the debugger.
b) No, don’t use DoEvents.[/quote]
A - I see the same thing - it happens in built macOS apps, as well.
B - App.DoEvents() is the only solution that I can find that works 100% since controlling these types of dialogs can only happen on the Main run loop.
So, if you have a solution that eliminates DoEvents in this scenario, I would LOVE to change over. I’ve even tried sending a setWindowsNeedUpdate(true) Obj-C call. But, for more than 14 years now, App.DoEvents() is the only thing I’ve found that handles 100% of the instances NOT caused by my code to update the UI. This applies to Linux and Windows, as well.
I’m pretty sure that at it’s core, this is the “updates don’t get pushed to the UI until the current event loop finishes” behavior. You know, the “you can’t update a progress bar in a tight loop” thing. Release the UI and the system has time to close the dialog. I would think that a non-doevents solution would likely involve a timer relay.
very much so
without disassembling what gets compiled as code I cannot be 100% sure but this little doevents hack certainly leads me to suspect that is exactly whats going on
the only upside to the code I posted is that rather than splitting your code into 2 pieces you can leave it more or less as it with linear flow & logic
that may be advantageous
You could use Timer.CallLater method and handle what you need to do with the folderitem in another method:
//Method or button.Action event that shows the dialog
Dim f As folderitem
Dim dlg As New SaveFileDialog
f = dlg.ShowModal
timer.CallLater(1, AddressOf HandleSaveFolderItem, f)And the HandleSaveFolderItem function
[code]Public Sub HandleSaveFolderItem(vf As Variant)
if vf.IsNull then
//Handle case where user clicked cancel
Else
//Do something with folderitem f
Dim f As FolderItem = vf
Break
end if
End Sub
[/code]
calllater has its own set of headaches (like if the object that holds the method you took the addressof is nil’d you can just crash with really weird errors)
The SaveFileDialog is modal, the Window that called it isn’t likely to be nil’d, and with a 1ms delay in the CallLater it isn’t likely to disappear either.
well that shouldnt be nil
famous
last
words
