File Open Dialog Blocks IDE on Breakpoint

I’m wondering if this happens only to me due to something in my setup, or if it’s the same for all. If I have code that calls a file open (probably save as well) dialog and I breakpoint somewhere in the code that executes not long after the dialog opens, the dialog box remains on screen in front of all applications, blocking the IDE, which makes debugging awkward to say the least. The breakpoint can be well after the result of the dialog has been handled, and I can step through a lot of code yet the dialog persists, and it’s difficult/impossible to predict how far down a breakpoint needs to be placed in order to avoid the problem. I’m running the IDE under MacOS 10.13, not sure if this has always been a problem or if it’s something recent.

I just did a test with the example from the LR
and yeah, the dialog stays there if breakpoints are included… in my case until the method was completed, even though the dialog was satisfied a few lines earlier

A workaround is to put a messagebox before the breakpoint. The problem will still occur, but if you can find the Step button to get to the messagebox call, the messagebox will make the file dialog go away. I don’t remember this ever happening with RS, not sure how far back it goes in Xojo.

As I recall, this was due to an OS update.

Wasn’t there an example from Ulrich Bogun how to work around this sometimes annoying issue?

Yes, but there is currently something wrong with https://xojoblog.me/ , which is a pity. @Ulrich Bogun : what’s up, dude?

Try:

https://blog.xojo.com/

@Emile Schwarz : sometimes I want to say something… Ulrich Bogun has his own blog in German. Looks like he hosed his website.

And it’s not fixable?

[quote=412291:@Emile Schwarz]Try:

https://blog.xojo.com/[/quote]
Lots of interesting info in the blog, but useless search function :frowning:

The operating system separates UI handling from code handling. So while the FolderItem is immediately available to you, the OS is taking it’s next available opportunity to close that window, and sees no need to immediately close it.

You may be able to can work around this the way we are supposed to for file drop zones. After you get the file, use a timer to push the FolderItem handling to (with a drop zone) after the app has released the FolderItem back to the Finder. You’ll still have a FolderItem to work with, but (in the case of drop zones) the Finder is no longer waiting for you to tell it what you’ve done with the file. Here, the goal is to simply keep a reference for the FolderItem, but tell the system it’s now okay to update the UI (and close the OpenDialog).

While this seems more complicated than how RealBasic used to work, I would imagine it helps it resolves the issue.

Here’s an example that works: https://www.dropbox.com/s/tsd6ek7zsez5gbp/OpenEvent.xojo_binary_project?dl=1
Licensed as free for all, do what you want.

Edit: Added example, confirmed working

[quote=412374:@Tim Parnell]The operating system separates UI handling from code handling. So while the FolderItem is immediately available to you, the OS is taking it’s next available opportunity to close that window, and sees no need to immediately close it.

You may be able to can work around this the way we are supposed to for file drop zones. After you get the file, use a timer to push the FolderItem handling to (with a drop zone) after the app has released the FolderItem back to the Finder. You’ll still have a FolderItem to work with, but (in the case of drop zones) the Finder is no longer waiting for you to tell it what you’ve done with the file. Here, the goal is to simply keep a reference for the FolderItem, but tell the system it’s now okay to update the UI (and close the OpenDialog).

While this seems more complicated than how RealBasic used to work, I would imagine it helps it resolves the issue.

Here’s an example that works: https://www.dropbox.com/s/tsd6ek7zsez5gbp/OpenEvent.xojo_binary_project?dl=1
Licensed as free for all, do what you want.

Edit: Added example, confirmed working[/quote]
Thanks for the explanation, Tim, but it seems to me that if there is low-level OS housekeeping that needs to be done in order to make breakpoints work usably, that housekeeping should be done by the IDE, not by adding workarounds to application code.