Window.Show method behavior change in 2024r4

What you’re referring to is correct and how the UI should behave, but it doesn’t dictate how the underlying code should run. There’s no reason you shouldn’t be able to show a window “modally” as far as the user is concerned and continue to run code in the background.

3 Likes

It is true if the user don’t break some hard rules. And touching the underlying UI is one of them. The modal moment should suspend the underlying UI and start some data collection of operations on top of it and return something that will be used by an UI in some specific state when it was invoked (the modal one), if I do allow the underlying UI processing and changing its state while in parallel we are doing things in the modal one, that is used basically to freeze the underlying one while they do its job and pass results back to the underlying window/state, some clashes may occur.

1 Like

Advanced users needing unstoppable background operations could fire a preemptive thread, they certainly should know what can be done without breaking things.

Where gotten off topic everyone.

The purpose was to note that this is a significant behavior change in the Xojo Framework which could affect a lot of users.

4 Likes

I think we are on topic, Is it possible that R4 is compiled with a new Apple SDK and is Apple enforcing the behavior they describe in their docs, and not Xojo?

I don’t recall a change in Apples docs about this or what their docs say about it.

Ok, so the method for showing a sheet is here:

The fact that it has a completion handler means that by design, it’s not blocking, and the completion handler fires when the window closes. That means that Xojo is probably artificially blocking code with the ShowModal method by default and that this behavior change is simply a regression brought on by another change in Sheets in 2024r4.

4 Likes

Yes, this was the point I was making when diving into the types of windows in conjunction with Show/ShowModal. There’s certain conventions you’d expect for a particular window type based upon semi-well established native OS conventions. Xojo may or may not reflect these conventions for each window type, but also adds another layer with Show/ShowModal.

My intention wasn’t to beat a dead horse, but instead to ferret out exactly what Xojo is doing and maybe what it should be doing. And of course, adding this to the documentation, to help folks down the road.

They should put the behavior back the way it was, because right now both Show and ShowModal do exactly the same thing, which is very limiting.

To be honest, I am very surprised that this didn’t break functionality in the IDE itself.

4 Likes

I completely agree with you especially after seeing the situation in the table above. :crossed_fingers::shamrock: that this gets fixed soon.

1 Like

Read few post above:

By default, a sheet is modal, presenting a targeted experience that prevents people from interacting with the parent view until they dismiss the sheet (for more on modal presentation, see Modality).

IF William did not change anything and R4 started to behave differently, Apple may changed things enforcing more the behavior (they are doing things like that lately) to avoid people breaking things and states between the host window and the hosted modal sheet as it was designed for. If William changed something, then let’s wait for a review of the behavior from Xojo under the lights of the docs and tests that they probably will run. I’m not saying you are right or wrong, I’m just presenting more info, questioning things and possibilities.

1 Like

Ok, for anyone that’s running into this problem, I have a workaround for now:

  1. Open the sheet window that you’re trying to show
  2. Add a New Method: Show(parent as DesktopWindow)
  3. Remove the code that calls the super method
  4. Add the following code:
#If TargetMacOS
  If parent = Nil Then
    parent = app.WindowAt(0)
  End If
  
  // - (void) beginSheet:(NSWindow *) sheetWindow completionHandler:(void (^)(NSModalResponse returnCode)) handler;
  Declare Sub beginSheet_completionHandler Lib "Foundation" Selector "beginSheet:completionHandler:" ( w As Ptr ,  sheetObj As Ptr , completionHandler As Ptr )
  
  beginSheet_completionHandler(parent.Handle, Self.Handle, Nil)
#Else
  Super.Show(parent)
#EndIf

That’s it!

NOTE: I’ve only been testing on macOS because that’s where the problem manifested for me. If it also is a problem for windows & linux, additional declares will need to be created.

1 Like

The very first sentence of that Apple link says “Modality is a design technique” and then proceeds to describe how modality works from a user’s perspective. It makes no statements or recommendations as to the code-level implementation of these behaviors.

If you have some Apple documentation that pushes developers toward stopping all other code while a modal dialog is in play, that might be more helpful.

Neither I did.

There are rules, like patterns. No one says “stop coding” or “stop code”, neither did I. The rules just says “avoid affecting the underlying state while the modal one is on play, we will try to isolate your current context (the modal one) from the underlying one, but we can’t avoid you doing things and hacks against such patterns, we just wish you avoid it. The modal sheet/view should receive a frozen underlying state, act, and the underlying state should receive back a return based on such state and resume the UI processing”. How is that implemented? I don’t care, I don’t need to care. I don’t think that what you did was helpful, very the opposed.

The only questions I introduced were: Is this new behavior forced by Apple? Was it introduced by a new SDK?

To support my questions I presented Apple docs.

Just it.