Ok, I’ve narrowed down the issue that I was noticing here. The actual problem was a change in how Window.Show behaves on macOS when the window being shown is a Sheet.
Consider the following code in the Opening event of Window1:
dim w as new SheetWindow // SheetWindow is a window with its Type set to "Sheet Window"
w.show(self)
Break
Depending on the version of Xojo you are using, the behavior is different:
In 2024r3.1 and below, the window is shown and the IDE breaks
In 2024r4 and above, the window is shown but you don’t reach the breakpoint
I can confirm, this is happening for me too. On macOS 14.7.2 with M3.
Using 2024r3.1, the Break happens after the SheetWindow opens.
Then 2024r4.1, the Breakdoes not happen until after SheetWindow closes.
Note: I wasn’t able to download your example project, so I created another simple example. Don’t know what other code you might have had in your sample.
Correct me if I’m wrong, but I’m pretty sure that the Sheet window type has always been a modal window type. It would therefore be correct for Show to behave like ShowModal because the window is a modal window type. So my guess is that changing the behaviour of the show function was actually a bug fix and the latest version is correct where previous versions got it wrong.
But related to this: as you no doubt already know, Apple changed the behaviour of the Sheet window type a few OS versions ago. The window used to drop down from the top of the parent. Now it appears in the “center” of the parent. This destroyed a lot of UI in existing apps because things which were previously visible become blocked when the sheet window is no longer at the top. Because of this change, I do not use the Sheet window type any more, and I’ve changed all the existing instances that used to be sheets to type Moveable Modal.
As you folks have heard me say before, you learn something new everyday. At first blush, I wasn’t sure if you were correct Greg, as I thought Sheets actually stopped code execution under macOS. But after looking further, you’re absolutely correct and I’ve given the ticket a thumbs up.
Although neither I or ChatGPT can find direct references for what behavior should be taking place (for Apple’s own Cocoa/AppKit/UIKit frameworks), ChatGPT believes the following:
Sheets: These are typically non-blocking; when a sheet is displayed, the code that presented it continues executing. Developers often handle user interactions with sheets asynchronously, using completion handlers or delegate methods to manage responses. Sheets in macOS are considered document-modal, meaning they block user interaction with their parent window but do not inherently stop the execution of code in your application.
Modal Dialogs: These are generally blocking; when a modal dialog is presented, it starts a modal event loop that halts further code execution in the calling method until the dialog is dismissed. This behavior ensures that the application waits for user input before proceeding.
So assuming this is correct and based upon Internet tribal knowledge, it sounds like something not just to be fixed, but maybe for the Xojo documentation to explicitly call out. I’ve created #78150 - Add Documentation on Code Execution for .Show, .ShowModal & .ShowPopover as a request for all of this to be documented as well.
One more follow up as I was pondering the implications on (MS) Windows but couldn’t get far enough down the path to articulate things. Then I found this:
Windows — Xojo documentation
On Windows and Linux, Sheet windows behave like Movable Modal Dialogs. This means if you are creating a cross-platform app you can design your dialogs as Sheets and they will works as Movable Modal Dialogs on Windows and Linux without you having to do anything specific.
This makes the path forward less clear as there’s now two competing thoughts for cross platform apps…
Xojo Adopts OS Specific Conventions
1.1 Sheets under macOS will NOT block code execution (2024r3.1).
1.2 As Sheets under Windows become Movable Modal Dialogs, they WILL block code execution.
1.3 In this scenario, Xojo is respecting the OS conventions but results in Xojo devs. needing to understand these underlying OS specific differences.
Xojo Adopts Sheets Blocking Code Execution
2.1 Sheets under macOS WILL block code execution (2024r4).
2.2 As Sheets under Windows become Movable Modal Dialogs, they WILL block code execution.
2.3. In this scenario, Xojo is breaking OS conventions to make a uniform behavior across OSes while making things more universal.
So the whole thing becomes quite a quandary…
If Xojo does #1, then how does a Xojo dev. invoke a dialog under Windows that also does NOT block code execution? I’m probably missing something here, but from what I can tell, this means if you’re using a sheet under macOS you’ll need to use a Document window under (MS) Windows to have the equivalent functionality.
On the other hand, if Xojo does #2, how does one invoke a dialog under macOS and Windows that does NOT block code execution? Once again probably missing something here, but this means a Document window as a dialog for both OSes.
Of course, there’s always another option of Xojo providing a property to .ShowModal to determine ceasing code execution or not, but I’m not really sure how feasible this might be based upon the underlying Apple and Microsoft frameworks.
There’s a difference between modal windows and showmodal.
Modal windows prevent the user from doing anything else while the window is visible.
ShowModal prevents the application from doing anything else while the window is shown.
What my application does is akin to the build dialog in Xojo. I show the dialog modally, do a bunch of processes in the background and then close the modal window when the last one finishes.
So using Greg’s project example and within my own testing…
2023r3.1
Show
ShowModal
macOS
Not Blocked
Blocked
Windows
Not Blocked
Blocked
2023r4
Show
ShowModal
macOS
BLOCKED
Blocked
Windows
Not Blocked
Blocked
So am I correct that the uppercase BLOCKED for macOS is then the problem?
Also am I correct then that Show and ShowModal then supersede what one would normally expect for modal types across macOS and Windows?
It looks like that’s the case in which case and if true, means that if you’re have a Window.Type that is Modal, and you use .Show to present it, then it’s not code blocking which is a bit counter-intuitive to how these OS windows generally work. I’m not saying I disagree as I think Xojo’s way of having some fine grained control is super useful, but instead just trying to wrap may head around all the intersections here.
Sorry if I’m being dense here. I’m trying to map Apple’s Cocoa/AppKit methodologies and patterns to Xojo’s. Looking specifically on the Apple side OOB…
Sheets
User Interaction Blocking
NOT Code Blocking (asynchronous code execution)
Modal Windows
User Interaction Blocking
Code Blocking (synchronous code execution)
From my understanding and experience, these are intrinsic qualities to the window itself. So I guess the .Show versus .ShowModal in Xojo might be equivalent to the Sheet being shown OOB versus with NSApp.runModal.
P.S. In the two tables above, the blocking I’m referring too is code blocking NOT user interaction.
Interestingly, code in other windows should be running, the code execution blocking should be targeted only for the window with such sheet, not app wide.
Should be true when shown using Show and false when shown using ShowModal.
Also always true. “Modal” in this case refers to the user side.
Again should depend: true when called with ShowModal and false when called using Show.
Think of it that way: the frame type defines modality for the user (it doesn’t mean anything about your code being asynchronous or synchronous), and Show/ShowModal defines whether your code will be synchronous or not (regardless of the frame for the user).
You can fairly well have a simple document window for which you call ShowModal and your code will wait until the window is closed, for instance. Here, there’s no modality at all for the user (he can use any other window while your code waits for the window to be closed).
There’s just one special case in Xojo: MessageDialog/MessageBox are always modal in both ways (user modal and code modal), but that’s another story.
A modal window is a window that belongs to a host window, and once displayed, assumes the UI and cuts the interaction with the host, that means that the user have no more access to the host UI until the modal window is dismissed. Just it. It’s used because next steps need data collected from the modal window.
Apple docs says Sheet on a Mac are always modal. That means that it needs to present the behavior I described using show() or showmodal().
