How to close a ShowSaveFileDialog

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 . 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

  1. it needs to go out of scope
  2. 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


seems 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

//Do something with folderitem f
Dim f As FolderItem = vf


end if

End Sub

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